Jira Software Questions and Answers

Here are the Jira Software Questions and Answers, based on my own understanding. If you want my complete set of Jira Questions and Answers, you can message me on LinkedIn at Inder P Singh.

Question: What is Jira? How is it used in software development projects?
Answer: Jira (see short Jira video) is a project management and issue-tracking tool developed by Atlassian. Originally featuring bug and issue tracking, Jira has evolved into a powerful tool used in Agile project management. It helps teams plan, track, release, and monitor software throughout the software development lifecycle. For SDETs (Software Development Engineers in Test) and QA engineers, Jira provides the functionality for managing test cases, tracking defects, monitoring progress, and cooperating with the development teams. It works with Agile methodologies such as Scrum and Kanban, allowing teams to manage sprints, backlogs, and releases. For example, an SDET might use Jira to track the progress of automated tests, create bug reports based on test results, or link test cases to specific user stories or epics in a sprint.

Question: Why is Jira popular in the software development industry?
Answer: Jira is popular because it adapts to various workflows and works well for teams of all sizes. It supports Agile practices (see Agile Methodology tutorials here), allowing teams to manage backlogs, sprints, and releases easily. Jira also integrates with many tools used by software development teams, such as Confluence, Bitbucket, and testing frameworks, making it a central hub for tracking progress. For QA teams, Jira simplifies bug tracking, test management (with plugins), and issue tracking. It's ability to generate reports and dashboards gives insights into the overall quality of the software.

Question: What are the Jira features that SDETs and QA engineers should know about?
Answer: Some of the key features that are useful for testing include:
- Issue Tracking: Jira allows users to create and track issues such as bugs, user stories, and tasks. This makes it easier to monitor the progress of testing, log defects, and link test results to development work. Example: A QA engineer can log a bug in Jira with detailed reproduction steps and assign it to a developer for fixing.
- Custom Workflows: Jira workflows help teams track the status of issues from start to finish. Each project can have a customized workflow that aligns with the team’s processes. Example: A testing team may create a workflow where bugs move through statuses like "Open," "In Progress," "Fixed," and "Closed."
- Test Case Management: Although Jira doesn’t have built-in test case management, it integrates with plugins like Zephyr and Xray. These tools help SDETs manage test cases within Jira, link them to user stories, and track execution results.
- Dashboards and Reports: Jira’s dashboards and reports allow teams to visually view the project progress, defect statuses, and test case execution. QA engineers can create custom reports to monitor open bugs or track testing coverage. Example: A QA engineer can create a report that shows the number of open bugs in the current sprint.
- Agile Boards: Jira supports both Scrum and Kanban boards. These boards help teams organize their work, track progress, to know if all tasks are being executed as expected. Example: A Scrum team may use Jira’s Scrum board to track user stories, bug fixes, and testing tasks in the sprint backlog.
- Automation and Integration: Jira integrates with Continuous Integration (CI) and Continuous Deployment (CD) tools like Jenkins. This allows automated test results to be linked directly to Jira issues, automatically updating their status based on test results. Example: When an automated test fails, it can trigger a Jira ticket or update an existing bug’s status.

Question: How does Jira help QA engineers manage bugs and defects?
Answer: Jira’s bug tracking system is easy to use and shows the status of the bugs. QA engineers can log bugs with detailed descriptions, screenshots, and logs. Each bug can be linked to a user story, assigned a priority, and tracked through the development process. Jira also supports a complete defect lifecycle, with stages like "Open," "In Progress," "Resolved," and "Closed." This allows the team to monitor how long bugs stay open, who is working on them, and how quickly they are resolved. Custom filters and dashboards also help QA engineers track specific types of defects, such as critical issues or bugs affecting certain features.

Question: How do you log in to Jira and navigate its interface effectively?
Answer: To log in to Jira, follow these steps:
- Open your browser and go to your company’s Jira URL
- Enter your credentials (email and password). If your company uses Single Sign-On (SSO), you may need to use your company credentials.
- After logging in, you will reach your Jira homepage, which usually displays recent projects or tasks you're working on.Navigating Jira’s interface:
- Top Navigation Bar: At the top, you’ll see options like Projects, Issues, and Boards. From here, you can navigate to various parts of Jira.
 - Projects: Clicking on this will show you a list of all your assigned projects. You can select any project to view its details, including backlogs, sprints, and boards.;
- Issues: This section allows you to view and manage all the issues (user stories, tasks, bugs) assigned to you or your team. You can also create new issues from here.
- Boards: This leads you to Agile boards (Scrum or Kanban), where you can see the flow of tasks, from to-do to done.
For example, if you're working in a sprint, you can navigate to the Boards section, select the sprint board, and drag user stories or tasks through their respective stages (To Do, In Progress, Done). The sidebar on the left may have shortcuts to recently viewed issues or boards, allowing you to quickly jump between tasks.

Question: What are the different user roles in Jira? How do permissions work in Jira?
Answer: Jira organizes users into roles, with each role having specific permissions and responsibilities. The main roles you may see are:
- Jira Administrator: The admin has full control over the system. He/she manages user accounts, project settings, and permissions. The Administrator can also customize workflows, create new projects, and set up security levels. Example: An admin can configure who has the right to transition an issue from "In Progress" to "Done."
- Project Administrator: A project admin manages a specific project. He/she can edit project settings like workflows and permissions within their project but doesn't have system-wide control. This role can perform project management without having full access to Jira settings. Example: A project admin can create custom fields for their project or modify the project’s board layout.
- Developer/Engineer: Developers work on tasks or issues assigned to them. They can change issue statuses, comment on tasks, and log time spent on them. They cannot change project settings but have control over their tasks and issues. Example: A developer marks a task as "In Progress" once they start working on it. - QA/Test Engineer: QA engineers can create, view, and update issues. They may have additional permissions to log bugs, execute tests, and track testing progress. They do not have access to project settings but can communicate with developers and project managers on issue statuses. Example: A QA engineer logs a bug, assigns it to a developer, and tracks its resolution throughout the sprint.
- Viewer/User: These are users who can view issues and tasks but cannot edit them. This role is often assigned to stakeholders or managers who need to monitor progress without making changes. Example: A product manager can view the progress of a sprint without making any direct updates to tasks.

Question: How is access control managed in Jira?
Answer: Access control in Jira is managed through permission schemes. These schemes define what actions users can take based on their roles. Permissions can be customized for each project, allowing admins to control who can:
- Create, edit, or delete issues
- Transition issues from one status to another
- Access reports, dashboards, or project boards
For example, only developers might have the permission to close a bug, while QA engineers can only move it to "Tested." The level of access is set up so that users can perform their necessary tasks without altering critical project settings.
In addition, Jira supports group permissions, where a set of users is grouped together (e.g. developers, testers), and permissions are assigned to the group as a whole. This simplifies managing permissions across multiple users and projects.

Question: What is a Jira ticket, and how do you create it?
Answer: A Jira ticket represents any task, bug, issue, or user story that is tracked within the Jira project management system. For example, the Jira ticket can a bug that needs fixing to a feature that needs development. 
Steps to Create a Jira Ticket:
- After logging into Jira, navigate to your project dashboard.
- In the top menu, click on the Create button.
- A ticket creation form appears. Select the Issue Type (e.g. Bug, Task, Story, Epic) based on what you're reporting.
- Fill in the Summary, Description, and other relevant fields (explained in detail below).
- Assign the issue to the appropriate team member using the Assignee field. You can leave this unassigned if you want someone else to pick it up later.
- Set the Priority to indicate the importance of the ticket (e.g. High, Medium, Low).
- Click Create to save the ticket, and it will appear in your project backlog or active sprint.

Question: What are the key fields of a Jira ticket, and what do they mean? 
Answer: When creating or managing a Jira ticket, several important fields help to define and track the issue:
- Summary: This is a brief, one-line description of the issue or task. It should be concise but clear and enough to give anyone looking at the ticket a quick idea of what it’s about. Example: "Fix the login issue on the customer portal."
- Description: This is a detailed explanation of the issue or task. Include steps to reproduce the problem, expected behavior, or specific requirements if it's a task. This field is used for providing context to whoever is working on the ticket. Example: "When users enter incorrect login credentials, the system crashes instead of showing an error message."
- Priority: Priority helps the user understand how urgent the task is. Jira allows you to set levels like High, Medium, Low, or Blocker. View Priority And Severity In Testing With Example tutorial here. Example: A "Blocker" priority might be given to a bug that prevents users from accessing the system.
- Assignee: The assignee is the person responsible for working on and resolving the issue. Assigning the correct team member enables accountability and makes the workflow smooth.
- Status: This shows the current state of the ticket. Common statuses include To Do, In Progress, and Done. But teams can customize these based on their workflow.
- Issue Type: Jira issues can be classified as Bug, Task, Story, Epic, or Sub-task. Each type defines the nature of the issue and how it should be addressed.
- Attachments: You can attach files like screenshots, logs, or documents to the ticket. This is useful when additional context is needed, especially for bugs.
- Comments: The comment section allows team members to discuss the issue, leave feedback, or ask for clarification. This is needed for collaboration in Jira.

Question: How do you track and update Jira tickets throughout their lifecycle? 
Answer: Tracking and updating Jira tickets effectively is needed for managing workflows and keeping the project on track.
- Updating Ticket Status: Each Jira ticket moves through various statuses as work progresses. Example: When a developer begins work on a task, he/she moves it from To Do to In Progress. Once the task is complete, he/she updates the status to Done. If it's a bug that needs validation by the QA team, the status might be changed to Ready for Testing.
- Adding Comments: Regularly update the ticket’s Comments section to provide progress updates or communicate with other team members. Example: A developer might add a comment saying, "Fixed the issue in the login module. Please test."
- Time Tracking: Jira has a built-in Time Tracking feature that allows team members to log the time spent on each ticket. This helps in measuring the effort required to resolve issues and can provide input data for sprint planning.
- Sub-tasks and Linking Issues: For larger tasks or user stories, you can break them down into smaller, more manageable sub-tasks. Additionally, if a ticket is related to or dependent on another issue, you can use the Linked Issues feature to show this relationship. Example: If fixing a bug depends on another feature being implemented, you can link the two tickets to indicate that one can’t proceed without the other.
- Using Jira Filters: Jira provides a robust filtering system to help you track issues. You can create custom filters to see only the tickets that are relevant to you, such as "My Open Bugs" or "All Critical Issues in Sprint".
- Dashboards and Reports: Jira’s dashboard feature allows you to view your ticket tracking. You can create custom dashboards to show information that is important for you, such as the number of tickets by status, priority, or assignee.
If you want FREE Software Testing, Testing Automation and AI-based Testing course, you can get them on this blog here.

Question: How do you raise and manage bugs in Jira?
Answer: Raising a bug in Jira is a straightforward process but needs details: Creating a Bug:
- Click the Create button in Jira.
- Choose Bug from the list of issue types.
- Fill out the Summary (a brief title of the bug). Example: "Login page crashes after entering valid credentials."
- Enter the Description (detailed steps to reproduce the bug). Example: Navigate to the login page. Enter valid username and password. Click login. The page crashes instead of logging in the user.
- Preferably attach supporting information like screenshots or log files.
- Set the Priority (e.g. High, Medium, Low) to indicate the urgency of the bug resolution.
- Assign the bug to a team member responsible for fixing it.

Managing Bugs:
Once created, bugs can be tracked throughout the software project lifecycle.You can update the bug by adding comments, changing the assignee, or modifying fields like status or priority.Bugs can be updated with statuses like Open, In Progress, In Review, and Closed to show their current stage.

Question: What is the bug lifecycle in Jira, and how is an issue resolved? 
Answer: The bug lifecycle in Jira represents the various stages a bug goes through from when it’s raised until it’s resolved. 

Bug Lifecycle Stages:
- Open: The bug has been logged but not yet assigned to a developer.
- In Progress: A developer is working on fixing the bug.
- In Review: The bug fix is complete and is awaiting review or re-testing by the QA team.
- Resolved: The bug has been fixed and tested, but verification may be needed.
- Closed: The bug is completely resolved, and no further action is needed.
- Reopened (optional): If the issue reappears or was not fixed correctly, it can be reopened and re-evaluated.

Issue Resolution:
- When a developer fixes a bug, the status changes from In Progress to In Review.
- The QA team then tests the bug fix to confirm it’s resolved.
- If the fix works as expected, the bug is marked Closed.
- If the issue still persists, the bug is Reopened, and the process starts over.

Question: How do you use Jira for managing Agile projects, especially Epics, Stories, and Tasks?
Answer: Jira is popular for Agile project management because it supports Scrum and Kanban methodologies through a customizable interface. See the Agile Methodology videos set here. Here's how Jira can be used to manage Agile projects:
- Epics: These are large user stories or features that can be broken down into smaller, more manageable units. An epic represents a high-level goal, that may need multiple sprints or iterations to be achieved. Example: "Improve User Authentication"
- Stories: User stories are smaller, specific features or functionalities that can be completed within a sprint. Stories typically represent a user need or functionality requirement. Example: "As a user, I want to log in using social media credentials." - Tasks: These are actionable items that need to be done to complete a story. Tasks are usually technical or testing work associated with implementing a user story. Example: "Implement OAuth for login."
Note: You can perform Agile Test Estimation easily using the Agile Test Estimator tool here.

Managing Agile in Jira:
- In Jira, you can create Epics and then link related Stories and Tasks under each epic.
- Agile boards in Jira (Scrum or Kanban) visually display the progress of epics, stories, and tasks, making it easy to track them.

Question: How do Agile workflows work in Jira?
Answer: Agile workflows in Jira help track the progress of tasks, stories, and epics across different stages of the software development lifecycle. Workflows can be customized to suit the needs of the team but typically follow this structure:
- Backlog: All planned stories, tasks, and epics are added to the backlog, representing work that needs to be done in the future. During sprint planning, items from the backlog are moved into the sprint.
- To Do: When a sprint starts, tasks and stories move into the To Do column, meaning that they are ready to be worked on.
- In Progress: Once a team member starts working on a task, it moves to the In Progress column. This helps the team track work that is actively being developed. 
- In Review/Testing: After development, tasks move to In Review or Testing, where they are tested by QA or reviewed by peers before moving to completion.
- Done: Once a task, story, or epic is fully developed, tested, and accepted, it is moved to Done, marking it as completed. Example Workflow: A user story “Implement social media login” starts in the backlog. Once the sprint begins, it moves to To Do. After a developer starts work, it’s marked as In Progress, followed by In Review when the implementation is complete. Once QA tests the feature, it moves to Done.

Question: How do you start and manage sprints in Jira?
Answer: To start and manage sprints in Jira, you might follow these steps:
- Create a Sprint: On your Scrum board, you’ll find the option to create a sprint in the backlog view. Click on “Create Sprint.” Add stories or tasks from the backlog to the sprint by dragging them into the sprint section.
- Plan the Sprint: During the sprint planning meeting, the team decides which stories or tasks will be completed in the upcoming sprint. You can assign tasks to team members and estimate their story points (effort estimation). You may want to use my Agile Test Estimator tool for planning your sprint.
- Start the Sprint: Once the sprint plan is ready, click the Start Sprint button. This will lock the selected stories into the sprint and start tracking their progress. A sprint usually lasts for 1-4 weeks, depending on the team's preferences.
- Manage the Sprint: The Scrum board displays the sprint's tasks in columns like To Do, In Progress, and Done. Move tasks across these columns as they progress. Jira also has the feature to add comments, log work, and track any blockers during the sprint.

Question: What is the sprint backlog, burndown charts, and velocity tracking in Jira?
Answer: Sprint Backlog: The sprint backlog contains all the user stories and tasks committed to the sprint. It's a prioritized list of work to be done during the sprint. Jira's Backlog view makes it easy to organize and manage items by dragging them into the sprint, with details like story points and task assignments available.
Burndown Chart: A burndown chart shows the team's progress throughout the sprint. It shows how much work remains and whether the team is on track to complete the sprint on time. Jira automatically generates this chart, updating it as tasks move to the Done column. The x-axis represents time (days in the sprint), and the y-axis represents remaining work (story points or tasks). A sharp decline means the team is finishing tasks, while a flat line indicates a lack of progress. Example: A burndown chart might show that by the middle of the sprint, half of the tasks are completed, indicating good progress. If it’s flat near the end, it suggests a risk of incomplete work.
Velocity Tracking: Velocity means the amount of work the team completes in each sprint, typically measured in story points. Jira tracks velocity by comparing completed story points across sprints, helping the team understand its capacity and estimate future sprints more accurately. Teams should try to maintain consistent velocity. If velocity fluctuates, it could indicate issues with task estimation or unforeseen challenges during the sprint. Example: If a team completes 30 story points in Sprint 1 and 28 story points in Sprint 2, the velocity is consistent. This data helps the team predict that they can complete around 30 story points in the next sprint.

If you need free training, view the Software and Testing Training channel (341 tutorials) complete playlists at https://www.youtube.com/@QA1/playlists

Agile Test Estimation Tool (QA Tools)

Agile Test Estimator

User Story Points to Hours Factor

Total User Story Test Effort: 0 hours

Other Tasks

QA Environment Preparation

Negative Testing Effort

Exploratory Testing Effort

Regression Testing Effort

Other Testing (Performance, Security etc.) Effort

Defects Logging and Re-testing Effort

Total Test Effort: 0 hours

How to Use Agile Test Estimator

The Agile Test Estimator is a tool that helps software development teams estimate the testing effort required for their projects. It allows users to input data for each user story, such as the number of testing points, and then calculates the total test effort based on a variety of factors, including the QA environment preparation effort, negative testing effort, exploratory testing effort, regression testing effort, other testing (performance, security, etc.) effort, and defects logging and re-testing effort. If you want to learn how to use it, please see the Agile Test Estimation tool tutorial.

To use the Agile Test Estimator:

1. Review the User Story Points to Hours Factor. If needed, adjust it according to your project.
2. Enter the following information for each user story:
   • User Story ID (optional): An identifier for each user story. If entered, it will appear in JSON and CSV exports.
   • Testing Points: The number of Story Points for testing of that user story. Note that the full Story Points consider the size of all tasks (development, testing, deployment, and so on).
   • Testing Effort: The test effort is the product of Testing Points and User Story Points to Hours Factor. It will be displayed automatically.
3. Enter the estimated effort in hours required for the following tasks, as needed:
   • QA Environment Preparation
   • Negative Testing
   • Exploratory Testing
   • Regression Testing
   • Other Testing (such as performance testing, security testing, etc., as in your Test Strategy)
   • Defects Logging and Re-testing
4. The total test effort will be displayed in the "Total Test Effort" field automatically.

Example Output:

User Story ID,Testing Points,Test Effort (hours)
Login,1,2
Add to Cart,3,6
Other Tasks,Test Effort (hours)
QA Environment Preparation,1
Negative Testing Effort,2
Exploratory Testing Effort,2
Regression Testing Effort,2
Other Testing (Performance, Security etc.) Effort,2
Defects Logging and Re-testing Effort,2
Total Test Effort,19

Agile Test Estimator Usage Notes:

• The Agile Test Estimator is a tool, not a replacement for human judgment. Use this tool in conjunction with your own knowledge and experience to estimate the testing effort for your project, release, or sprint.
• The default values for the other tasks, such as QA environment preparation effort and negative testing effort, are reasonable for most projects. However, you can adjust these values as needed.
• The Agile Test Estimator can be used to estimate the testing effort for individual user stories or for your entire project.
• The Agile Test Estimator can export the test effort estimates to JSON format, for integration with test management tools or reporting tools.
• The Agile Test Estimator can export the test effort estimates as a CSV report. You can open this CSV report in Excel and share it with your team members or stakeholders.

Agile Test Estimator Contact Information

If you have any question or comment or bug report, use the Contact Us form (on the right) or email the developer at isingh30@gmail.com please.

Test Documentation: What do you mean by Test Documentation?

Great job on starting a new lesson! After reading this lesson, click Next button at bottom right to continue to the next lesson.

What do you mean by Test Documentation?

Test documentation is the documentation or creation of artifacts before or during the software testing. Documentation helps you to estimate testing effort, compute test coverage, do resource tracking, find test execution progress, etc. Also, it provides a systematic approach to software testing and acts as training material for new testers. Test documentation includes a variety of documents such as test policy, test strategy, test plan, test case, test data, defect report, test summary report, etc.

What are the types of Test Documentation: examples

• Test policy: It describes the testing goals, principles, methods of an organization. It defines the scope and standards of testing activities and the roles and responsibilities of the testing team.
• Test strategy: It identifies the test levels (types) to be executed for a project. It outlines the test objectives, test approach, test techniques, test tools, test environment, test deliverables, etc.
• Test plan: It is a detailed document that has the scope, approach, resources, schedule, etc. of software testing activities. It also specifies the entry and exit criteria, risk analysis, contingency plan, etc.
• Test case: It has a group of input values, execution preconditions, test steps, expected results, output values and post-conditions.
• Defect report/ Bug report/ Issue report: It is a report of any flaw in the software, such that the system fails to perform its expected function. Defect report contains the defect description, defect severity, defect priority, defect status, defect resolution, etc.
• Test summary report: It is a high-level document that summarizes the testing activities done and the test results. It also contains the test metrics, test coverage, test issues, test recommendations, etc.

Tips for test documentation

• You should start test documentation in the initial phase of the project, in parallel with the development process.
• Document what is needed for you to understand your work and what you need to produce to your stakeholders. Avoid unnecessary or redundant information, to reduce documentation effort or inconsistency.
• Use version control to manage and track your test documents and avoid duplication.
• Update the test documentation whenever there are significant changes in the requirements or design of the software system
• Follow the standards and guidelines of your organization and project for creating and maintaining test documentation.

FAQ (interview questions and answers)

1. What is the difference between a test scenario and a test case?
   A test scenario is a situation that could be verified by one or more test cases. A test case is a group of input values, execution preconditions, test steps, expected results, output values and post-conditions that validates a test scenario.
2. What is the purpose of a requirement traceability matrix (RTM)?
   It is a document that connects the requirements to the test cases. It helps to ensure that all the requirements are covered by at least one test case and helps to track the changes in requirements or test cases.
3. What are some common types of test documents?
   Test policy, Test strategy, Test plan, Test case, Test data, Defect report and Test summary report.

Remember to just comment if you have any doubts or queries.

 

Continuous Testing

Great job on starting a new lesson! After reading this lesson, click Next 👉 button at bottom right to continue to the next lesson.

Continuous Testing is a fundamental practice in Agile testing that involves running automated tests throughout the software development lifecycle to provide rapid feedback on the quality of the application. It aims to ensure that the software is always in a releasable state, helping early defect detection and allowing for frequent integration and deployment.

Continuous Testing Examples

• You work in a DevOps team that practices Continuous Testing. Whenever a developer commits code changes, a comprehensive suite of unit tests is automatically executed to validate the correctness of the changes.
• Your organization follows Continuous Testing by implementing a continuous integration and delivery pipeline. Automated tests, including functional tests, regression tests, and performance tests, are integrated into the pipeline to ensure that each code change is thoroughly tested before deployment.
• A mobile app development team employs Continuous Testing by leveraging cloud-based testing services. They run automated tests on various real devices in parallel to ensure compatibility across different platforms and screen sizes.
• An e-commerce company practices Continuous Testing by incorporating user experience testing. They continuously monitor user behavior using analytics and conduct A/B testing to assess the impact of design changes and optimize the buyer experience.

Tips for Continuous Testing

• Automate as many tests as possible to reduce the effort required for manual test execution and enable faster feedback.
• Integrate testing into the development and deployment process to catch defects early and prevent their accumulation.
• Adopt a shift-left approach by involving testers from the beginning of the development cycle to identify defects early and mitigate risks.
• Leverage virtualization and cloud-based testing services to enable parallel execution on multiple platforms and configurations.

FAQ (interview questions and answers)

1. Is Continuous Testing only applicable to Agile projects?
   No, Continuous Testing can be applied to other software development methodologies, like DevOps, and waterfall. It emphasizes the need for early and frequent testing throughout the development lifecycle.
2. Does Continuous Testing eliminate the need for manual testing?
   No, rather Continuous Testing complements manual testing. While automated tests provide fast and consistent feedback, manual testing is still necessary for exploratory testing, usability testing, and other test types that require human judgment and creativity.
3. Can Continuous Testing help improve the overall software quality?
   Yes, Continuous Testing aims to identify issues early in the development process, allowing for prompt defect fixes and reducing the technical debt.
4. Is Continuous Testing only focused on functional testing?
   No, Continuous Testing encompasses various types of testing, including functional, performance, security, and usability testing. The goal is to validate different aspects of the software continuously.

Remember to just comment if you have any doubts or queries.

Behavior-Driven Development

Great job on starting a new lesson! After reading this lesson, click Next 👉 button at bottom right to continue to the next lesson.

Behavior-Driven Development (BDD) is an Agile approach that focuses on collaboration and communication among developers, testers, and business stakeholders. It emphasizes defining the desired behavior of the system using natural language specifications. BDD promotes shared understanding of the business requirements and user expectations.

Behavior-Driven Development Examples

• A software development team follows BDD by writing scenarios using a Given-When-Then format to describe the behavior of a new feature. They involve the business in the creation of these scenarios to ensure alignment with the requirements.
• A web application team practices BDD by using a tool like Cucumber to define executable specifications in a natural language format. They collaborate with product owners to write scenarios that cover various user interactions.
• A mobile app development team uses BDD to write automated acceptance tests that validate the behavior of the app across different devices and platforms. They specify the expected outcomes in a clear and concise manner, making it easier for both developers and testers to understand.
• An e-commerce company applies BDD by defining scenarios that cover the end-to-end user journey, including browsing products, adding items to the cart, and completing the logout process

Tips for Behavior-Driven Development

• Involve the business stakeholders, domain experts and end users in the creation of behavioral scenarios.
• Focus on clear and concise specifications that can be easily understood by both technical and non-technical team members.
• Use a BDD framework or tool that supports the natural language syntax to facilitates collaboration.
• Ensure that the scenarios cover a wide range of possible user interactions including edge cases.

FAQ (interview questions and answers)

1. Can BDD be applied to legacy systems or only for new development?
   BDD can be applied to both new development and legacy (existing) systems. It helps in understanding the behavior of the legacy system and can guide the improvement or refactoring process.
2. Is BDD limited to certain programming languages or technologies?
   No, BDD can be implemented with various programming languages and technologies. There are BDD frameworks and tools available for different platforms and languages.
3. Does BDD replace the need for other testing practices like unit testing or integration testing?
   No, rather BDD complements other testing practices. Unit testing and integration testing are still needed to validate the functionality at different test levels.
4. Can BDD help in improving collaboration between developers and testers?
   Yes, BDD promotes collaboration by providing a shared language and understanding between developers, testers, and business stakeholders. It encourages early discussions and clarifications, reducing confusion, misunderstanding and rework.

Remember to just comment if you have any doubts or queries.

Test-Driven Development

Great job on starting a new lesson! After reading this lesson, click Next 👉 button at bottom right to continue to the next lesson.

Test-Driven Development (TDD) is an Agile testing practice where you write automated tests before writing the code. It follows a cycle of writing a test, writing the code to pass the test, and then refactoring the code. TDD helps ensure that the code meets the the desired functionality and improves test coverage.

Test-Driven Development Examples

• A web development team starts by writing a failing unit test for a specific functionality. They then write the minimum code required to pass the test, continuously running the test to ensure it remains passing. Once the test passes, they refactor the code to improve its quality and remove any duplication.
• A mobile app development team follows TDD by writing a failing test case for a new feature. They write the code incrementally, ensuring each step passes the test. They frequently run the tests on different devices to ensure compatibility and functionality.
• A software development team working on an API follows TDD by writing failing integration tests that validate the expected behavior. They then implement the code to pass the tests, making iterative improvements and continuously running the tests to ensure correctness.
• A software team developing a financial application applies TDD by writing tests for complex calculations. They write failing tests that cover various scenarios, implement the calculations incrementally, and validate the results against the expected values.

Tips for Test-Driven Development

• Start with small and focused tests that validate specific functionality.
• Write just enough code to make the failing tests pass.
• Refactor the code to improve its design, and other quality attributes like readability, and maintainability.
• Ensure a good balance between test coverage and development speed.

FAQ (interview questions and answers)

1. Is Test-Driven Development suitable for all types of projects?
   Yes, Test-Driven Development can be beneficial for various types of projects, including web development, mobile app development, API development, and complex calculations.
2. Can you write tests using Test-Driven Development without having the complete requirements?
   Yes, you can write tests using Test-Driven Development even when you have incomplete requirements. The tests act as executable specifications, guiding the development process.
3. Does Test-Driven Development replace the need for manual testing?
   No, rather Test-Driven Development complements manual testing. Manual testing is still needed to cover scenarios that are difficult to automate.
4. Does Test-Driven Development guarantee bug-free code?
   Test-Driven Development does not guarantee bug-free code. It is still essential to perform thorough testing.

Remember to just comment if you have any doubts or queries.

Agile Testing Principles and Practices

Great job on starting a new lesson! After reading this lesson, click Next 👉 button at bottom right to continue to the next lesson.

Agile testing is software testing in which you follow the principles of Agile software development. It involves all members of a cross-functional Agile team to deliver business value to the customer, at frequent intervals (typically between 2 weeks and 2 months). Agile testing uses various test types and techniques like test-driven development, behavior-driven development, and continuous testing.

Agile Testing Examples

• A web application team uses test-driven development (TDD) to write automated unit tests before coding each user story. They frequently run tests to ensure code quality and functionality. The team also applies behavior-driven development (BDD) to write acceptance tests using a natural language syntax (called Gherkin) to align with customers language.
• A mobile app team practices continuous testing by running automated tests on every code change using a continuous integration tool. They simulate different mobile devices using a device virtualization tool and perform tests on real devices in different geographical locations using a cloud-based testing service. Test results and metrics are monitored through a dashboard.
• A cloud-based application team uses service virtualization to test the application. They create and use virtual services that simulate real web services using a service virtualization tool (Postman). Performance testing using a tool (JMeter) determines scalability and reliability under different load conditions.
• A desktop application team does exploratory testing to test new features and functionalities without predefined test cases or scripts. They prioritize testing based on complexity and importance using a risk-based approach. Customer feedback is collected through a feedback tool.

Tips for Agile Testing

• Follow Agile testing best practices like short feedback iterations, testing alongside development, involving all team members, and using lightweight documentation.
• Per your test plan, apply test techniques like test-driven development, behavior-driven development, continuous testing, exploratory testing, parallel testing, cross-browser testing, regression testing, or performance testing to increase testing coverage and efficiency.
• Focus on relevant testing metrics to measure and monitor the progress and quality of Agile testing.

FAQ (interview questions and answers)

1. What is the purpose of Agile testing?
   The purpose of Agile testing is to deliver business value desired by the customer at frequent intervals, working at a sustainable pace.
2. What are the benefits of Agile testing?
   Agile testing helps determine the quality of software, enhances communication and collaboration among testers and team members, and supports continuous improvement of the software.
3. What are the challenges of Agile testing?
   Testers face challenges such as changing requirements requiring test design updates, fast project pace, and the need for frequent interactions with team members, clients and end users.

Remember to just comment if you have any doubts or queries.

Agile Testing

Great job on starting a new lesson! After reading this lesson, click Next 👉 button at bottom right to continue to the next lesson.

Agile testing is a software testing practice in which you follow the principles of Agile software development. Agile testing involves all members of a cross-functional Agile team to ensure delivering of the business value to the customer at frequent intervals. Agile testing uses various test types and various techniques such as test-driven development, behavior-driven development, and continuous testing.

Agile Testing Examples

• A web application team uses test-driven development (TDD) to write automated unit tests before writing the code for each user story. The team runs the tests frequently to test the code quality and functionality. The team also uses behavior-driven development (BDD) to write automated acceptance tests using a natural language syntax (Gherkin) that describes the expected behavior and outcomes of each user story. The team runs the acceptance tests frequently to test the alignment with customer expectations.
• A mobile app team uses continuous testing to run automated tests on every code change using a continuous integration tool. The team uses a device virtualization tool to simulate different mobile devices. The team also uses a cloud-based testing service to run automated tests on real devices in different geographical locations and networks. The team monitors the test results and metrics using a dashboard.
• A cloud-based application team uses service virtualization to test the application. The team uses a service virtualization tool (Postman) to create and use virtual services that simulate the behavior and data of real web services. The team also uses a performance testing tool (JMeter) to test the application scalability and reliability under different load conditions.
  
• A desktop application team uses exploratory testing to test new features and functionalities without predefined test cases or scripts. The team uses a risk-based approach to prioritize the areas to test based on their complexity and importance. The team also uses a feedback tool to collect customer feedback on their application.

Tips for Agile Testing

• Use Agile testing best practices such as shortening feedback iteration, testing alongside development, involving all team members, and using lightweight documentation.
• Use test techniques such as test-driven development, behavior-driven development, continuous testing, exploratory testing, parallel testing, cross-browser testing, regression testing, or performance testing that can help you to increase your testing coverage or your efficiency.
• Use only relevant testing metrics.

FAQ (interview questions and answers)

1. What is the purpose of Agile testing?
   Deliver the business value desired by the customer at frequent intervals, working at a sustainable pace.
2. What are the benefits of Agile testing?
   It helps find out the quality of your software. It enhances the communication and collaboration among testers and other team members. It supports continuous improvement of your software.
3. What are the challenges of Agile testing?
   The requirements may change at any time, which requires test design updates and testing. The project pace can be fast.  Frequent individual interactions with the team members or working directly with the client and end users or  may be challenging, depending on one's nature.

Remember to just comment if you have any doubts or queries.

Scrum Values | Scrum Vs Agile | Scrum Values Retrospective | Scrum Values Explained | Scrum Master

This blog post is on Scrum. I will explain Scrum values, the difference between Scrum and Agile, the importance of Scrum retrospectives, the five core values of Scrum and the role of the Scrum master. First, please view Agile values video. Next, please view my Scrum values video below for a detailed understanding or read on.

Scrum vs Agile: The difference between Scrum and Agile is that Agile is a project management methodology that emphasizes flexibility and rapid iteration, but Scrum is an Agile framework that is specifically designed for software development. While both Agile and Scrum share some values and principles, Scrum has a more defined structure and roles e.g. the Scrum Master. The Scrum business value is that Scrum helps rapid iteration and continuous improvement, which allows teams to quickly adapt to changing business needs and deliver value to their customers.

Scrum Values Retrospective: Retrospectives (or Retros in short) are meetings. Retrospectives are an important part of Scrum and help teams reflect on their performance and identify  improvement opportunities. The goal of any Scrum retrospective is to improve the team's performance and achieve the Scrum values. In a retrospective meeting, the Scrum team figures out how to apply the Scrum values.

Scrum Values explained: There are Scrum pillars and values. Scrum is based on three pillars: transparency, inspection and adaptation. There are 5 values in Scrum. The three pillars support the five values of Scrum. The Scrum values are Commitment, Courage, Focus, Openness and Respect:

1. The first of Agile Scrum values is Scrum Value Commitment. Suppose a team member is consistently not completing the tasks they commit to during sprint planning. How can the team address this issue in a way that aligns with the Scrum value of Commitment? The possible solutions are that the team can have a conversation with the team member to understand the reasons for their lack of follow-through and work together to find a solution. The team can also help the team member to identify an appropriate level of commitment and provide support to help them achieve it. 
2. The second of 5 Scrum values is the Scrum Value Courage. Suppose a team member is afraid to speak up about a problem that they have identified in the project. How can the team address this issue in a way that aligns with the Scrum value of Courage? The possible solutions are to have a culture where it is safe to raise concerns and by encouraging team members to speak up. The team can also provide support and resources to help the team member overcome their fear and take action.
3. The third of Scrum team values is the Scrum Value Focus. Suppose the team is continuously getting sidetracked and not completing all of their tasks. How can the team address this issue in a way that aligns with the Scrum value of Focus? The possible solutions are by setting clear goals and priorities for each sprint. The team can establish daily scrums to stay on track and remove any distractions. The team can also work together to identify and remove any obstacles that may prevent them from staying focused.
4. The fourth of five scrum values is Scrum Value Openness. Suppose the team is not receiving feedback from stakeholders like the client on a regular basis. How can the team address this issue in a way that aligns with the Scrum value of Openness? The possible solutions are by reaching out to stakeholders for feedback regularly and encouraging open communication. The team can also establish a culture of continuous improvement and seek feedback from stakeholders actively to drive progress.
5. The fifth Scrum Value is Respect. Suppose a team member interrupts others during meetings, not allowing them to speak. How can the team address this issue in a way that aligns with the Scrum value of Respect? The possible solutions are by having a conversation with the team member to explain the impact of their behavior on the team. The team can have ground rules for meetings and enforce them strictly. The team can give an opportunity to the team member to understand how their behavior affects the team and encourage them to respect the opinions and contributions of their team members.

Scrum Master: The Scrum master is a facilitator who helps the team work together effectively and efficiently. They are responsible for removing any obstacles that may prevent the team from achieving their goals and help the team follow Scrum values and principles. Agile Scrum Master is someone who has been trained and certified in the Scrum framework. They should have a deep understanding of Agile principles and be able to guide teams in the successful implementation of Scrum. 

 

Conclusion: Scrum values are important to the successful implementation of Scrum. Remember to keep the values of commitment, courage, focus, openness and respect in mind to have a productive and efficient team. The role of the Scrum Master is crucial in guiding the team to follow Scrum values. Thank you 🙏

Agile Values | Agile Values Vs Principles | Agile Values Explained | Agile Manifesto Values | Agile Software Development

This blog post is on Agile values. Four Agile values explained with examples in this post. The Agile Manifesto is a collection of values and principles behind those values for Agile software development and Agile software testing. View my Agile Values and Agile Values Vs Principles video below or read on.

Agile methodology aims to develop software in an efficient and flexible way. The first of core Agile values is individuals and interactions over processes and tools. So an Agile team may have regular face-to-face meetings with the product owner and the client to show the working software and gather feedback. The Agile team may work in pairs for more knowledge sharing.

Next in Agile core values is working software over comprehensive documentation. Now in Agile development, the team values the item on the right also, which is documentation but the Agile team values the item on the left more. So focusing on working software as one of the values of Agile, the team may deliver working software incrementally on a regular basis, like every two weeks, without worrying about detailed documentation. In addition, the team may use automated testing to get feedback about software quality.

The next in four values of Agile is customer collaboration over contract negotiation. In Agile project management, the team collaborates with the product owner or the client directly to get the requirements and share updates about the working software instead of using a detailed contract containing the project scope. This collaboration helps create a culture of trust in the Agile project. Question: a customer is too busy to provide feedback during a project and just wants everything to be as specified in the purchase order. Which Agile value does this violate? The answer is customer collaboration over contract negotiation. By not providing feedback, the customer is not collaborating. Due to this, the team may fail to deliver the correct software because everything cannot be spelled out in the contract, that is referred to in the purchase order. 

The last in Agile four values is responding to change over following a plan. This value of Agile makes a team welcome change. The team may use Agile practices instead of following a fixed plan. The team may also conduct retrospectives, which are meetings to analyze their Sprint and adapt their processes accordingly. Question: after the Agile team began the development, the client wants to change the scope of the project so the team decides to use Agile practices like user stories, backlogs and sprints to manage and prioritize the project requirements. Which Agile value is the team observing? The answer is responding to change over following a plan. These Agile practices will allow the team to respond to change better.

After four core values of Agile, you should also know about 12 Agile principles. The Agile Manifesto principles are detailed guidelines for the Agile values. The difference or Agile values vs principles is that the principles give guidelines on how to actually observe the Agile values in the project. Here is my summary of 12 Agile principles. Customer satisfaction is the highest priority. The team should achieve customer satisfaction by continuous delivery of value in working software. Also the team should welcome changing requirements. The team should reflect at regular intervals and change the processes to become even more effective. The team should have soft skills like collaboration, motivation and the team should be empowered. Face-to-face communication is the most effective way to exchange information within the team. The team should focus on technical excellence and simplicity in the software

Want to learn systematically and with more examples? View my Agile values video. Thank you 🙏

BDD with BDD full form (BDD stands for) | BDD Cucumber | BDD meaning | BDD testing | BDD vs TDD

Do you want to know the difference between BDD, TDD and ATDD? View my BDD, TDD and ATDD video or read this blog post.

 

In this blog post, I will explain what is BDD, what is Test Driven Development and ATDD vs TDD. BDD full form is Behavior Driven Development. Here is a Behavior Driven Development example. A Feature is a higher-level functionality provided by the system so for example a Feature can be place an order. A User Story explains the system behavior in non-technical language that everybody on the team can understand. The example of a User Story for the place an order Feature is As a customer I want to be able to place an order on the e-commerce website so that I can purchase the items that I need. 

 In the Cucumber Test there is the Scenario, which gives us steps and expected results of a test. So for example, the Scenario is successfully place an order. Given means the preconditions of the Scenario so Given a customer is on the website And the customer has added items to their shopping cart. When means the actions or operations or the steps of the test. When the customer clicks the checkout button. Then means the expected result. Then the order is successfully placed. In Java, this User Story may be implemented by using a public class like OrdersUtility, which is going to have a public method called placeOrder and it needs an Item object and the Customer object. There is a list of items placed by the customer in their shopping cart and a customer. So using a list of item objects and the customer object, the developers have to write the code to process in order and update the database.

 

BDD stands for Behavior Driven Development. BDD is used in Agile software development. As introduction to Behavior Driven Development, you should know that its focus is on system behaviors or application behaviors. BDD uses User Stories that explain the system behavior in a non-technical language. BDD testing uses Tests to verify those system behaviors. In BDD, the common Behavior Driven Development software testing tools are Cucumber that allows tests to be written in English. Cucumber may be used in a BDD Cucumber framework with Selenium. JBehave is used for testing web applications. SpecFlow is a tool for testing .NET applications. JBehave and SpecFlow allow tests to be written in a natural language syntax. 

 

TDD full form is Test Driven Development. The focus of Test Driven Development in software engineering is on system requirements and to write code so that it is simple to test the individual components. Test Driven Development vs Behavior Driven Development uses functional requirements and tests. Also, the common testing tools are different in Behavior Driven Development vs Test Driven Development or BDD vs TDD. In TDD the common testing tools are JUnit for testing Java applications or NUnit for testing.NET applications. If you want to know ATDD vs TDD, ATDD full form is Acceptance Test Driven Development. In Acceptance Test Driven Development ATDD, the focus is on system requirements of the whole system, which is different from TDD's focus on requirements of individual components. ATDD uses Acceptance Criteria which is commonly documented as User Stories and Acceptance Tests. In ATDD, the Acceptance Tests are written before writing the code that would pass those Acceptance Tests. The common testing Tools in ATDD include FitNesse, which allows writing Acceptance Tests in natural language syntax, Cucumber or JBehave. 

 

I hope that you know BDD meaning and have an idea about BDD Behavior Driven Development, ATDD and Test Driven Development TDD in Agile. If you want to understand BDD with more examples, please view my BDD video. Thank you!

Agile Backlogs: Understanding Product, Sprint and Bug Backlogs

Are you a QA, Software Engineer or Product Owner who wants to understand backlogs in Agile and Scrum? View my Backlog Agile video or read on.

Agile development is about adaptability, collaboration and continuous delivery of value to the customer. Agile uses the concept of backlogs. I will explain what is Backlog in Agile and Scrum, what are the types of Backlogs in Agile methodology, the relationship of Agile Product Backlog to Bug Backlog and Agile Product Backlog vs Sprint Backlog, who writes the backlog items in Agile and where to put bug fixes in Agile.

First, what is Backlog in Agile? It is pending work that will bring value to the customers. It is a list of items that need to be completed in the project and includes features, user stories and other tasks. What are features in Agile Scrum backlog? They are higher level functionalities provided by the system, for example a feature for users to customize their profiles and another feature to give personalized recommendations to users based on their past transactions. What are user stories? A user story explains a software feature in non-technical or business language. What are the other tasks in Agile Product Backlog? They are tasks to achieve the project goals but each task should provide value to the users for example refactor the code to improve performance, update the test scripts, system testing or QA testing focusing on functional testing and performance testing or update user documentation. 

There are three types of backlogs in Agile:

1) The primary or biggest backlog in Agile is the Product Backlog. It contains all the items that need to be done in the project, and it's the responsibility of the Product Owner to add items to it and prioritize them by business value. 

2) The Sprint Backlog is a smaller backlog. It contains all the items that need to be done in the current sprint. The Developers select items from the Product Backlog, estimate the efforts and add them to the Sprint Backlog.

3) When it comes to bug fixes, the Agile approach is to address them as soon as they are discovered. The Bug Backlog is a list of all the known bugs that need to be fixed in the project. The Product Owner is responsible for prioritizing the bug fixes, based on their impact to the users and customers.

There are different ways to handle the Bug Backlog, depending on the team's preference. One approach is to keep the Bug Backlog separate from the Product Backlog. This allows the Product Owner to focus on prioritizing the bug fixes without being overwhelmed by other items in the Product Backlog. However, this approach also introduces more overhead work for the team.

The typical approach is to include the Bug Backlog within the Product Backlog. This approach simplifies the process of prioritizing bug fixes, as the Product Owner can address them alongside other items in the Product Backlog. However, this approach makes it more difficult to track the status of bugs, as they are mixed in with other items.

In order to manage the Bug Backlog, the team can use a tool like Jira to prioritize and track the Product Backlog Items (PBI). The Product Owner can create Product Backlog Jira by adding items, setting their priorities and assigning items and the progress can be tracked by the Agile Scrum Master, Developers and other team members. 

In conclusion, the create Backlog and Sprint in Agile process is that the Product Owner adds PBI's including bug fixes needed to Product Backlog, prioritizes each PBI and cleans up the PBI's, as needed. Then for each Sprint, the Developers select the PBI's, estimate them and commit to deliver them in the Sprint. I hope that now you know about Agile backlogs, which are Product Backlog, Sprint Backlog and Bug Backlog. Thank you 🙏