What is an issue?

In Jira, teams use issues to track individual pieces of work that must be completed. Depending on
how your team uses Jira, an issue could represent a project task, a helpdesk ticket, a leave request
form, etc. In Jira Software, issues typically represent individual work items such as big features,
user requirements, and software bugs. You can update issues to show work progress or add
relevant information such as who is assigned to the work, in-depth description, or attachments.

What are issue types?

Jira Software has different issue types that can help you identify, categorize, and distinguish
between different types of work. The issue types out-of-the-box include:

Epic

Represents a larger body of work. Epics are often represented as a collection of multiple issues.
Example: Start a lemonade stand.

Task

Represents a task that needs to be done. Tasks are used as ‘catch-alls’ and when the work cannot
be accurately represented by the other issue types.
Example(s): Make lemonade. Create sign. Set-up stand.

Story

Represents a requirement expressed from the perspective of the user.

Example: As a lemonade enthusiast, I’d like to have a really cold, crisp drink.

Bug

Represents a problem that needs to be fixed.

Example: The lemonade is too sour.
Sub-task

Represents a more granular decomposition of the work required to complete a standard issue. A
sub-task can be created for all issue types.
Example: Squeeze lemons.

Sub-tasks are child issues that can be added after an issue has been created.

Epic

 An Epic captures a large body of work. It is essentially a large user story that can be
broken down into a number of smaller stories. It may take several sprints to complete an
epic.
 Big, coarse-grained
 Large themes, overall goals
 Epic is created by PTL
 Epic is never entered as a reference in Gerrit Commit to a Jira Issue ID. (because
Epic is very big, and can't be implemented within 1 single commit)
 It may takes multiple Sprint to implement an Epic

Story

 A Story or user story is a software system requirement that is expressed in a few short
sentences, ideally using non-technical language
 Non-technical language, Story expresses user needs using the syntax below

User Story Syntax

As a <user> = who
I want to <be able to do ABC> = what
So that <XYZ can be done> = why

 Story is created by PTL

 The scope of a Story should be addressed within a single Sprint
 Story is rarely entered as a reference in Gerrit Commit to a JIRA Issue ID

Task

 A Task represents a technical activity, like design a diagram, code a functionality, test a
device, or prepare dataset
 A Task contains description of individual work item (detailed, technical)
 A Task can be shared, assigned, relate to, depends/depended on by, blocks/blocks by
 A Task can be created by anyone
 Task is entered as a reference in Gerrit Commit to a JIRA Issue ID

What are linked issues?

As with any project, there may be dependencies between your tasks. You can easily represent
this association in Jira Software by linking issues together. Associations that come out-of-the-
box are:

 blocks/is blocked by
 clones/is cloned by
 duplicates/is duplicated by
 relates to

Sub-Task

 A Sub-Task is similar to a Task

 A Sub-Task is typically one of many tasks that make up a Story
 A Sub-Task is created from a Story. You cannot create a sub-Task from the Create Issue
button
 Breaks-up stories into digestible workloads
 A Sub-Task is created by anyone
 A Sub-Task is entered as a reference in Gerrit Commit to a JIRA Issue ID

What is the Agile methodology?

Agile methodology is a project management framework that breaks projects down into several
dynamic phases, commonly known as sprints.
The Agile framework is an iterative methodology. After every sprint, teams reflect and look back
to see if there was anything that could be improved so they can adjust their strategy for the next
sprint.

Agile methodologies

The Agile framework is an umbrella for several different variations. Here are a few of the most
common Agile methodologies.

Kanban

Kanban is a visual approach to Agile. Teams use online Kanban board tools to represent where
certain tasks are in the development process. Tasks are represented by cards on a board, and
stages are represented in columns. As team members work on tasks, they move cards from the
backlog column to the column that represents the stage the task is in.

This method is a good way for teams to identify roadblocks and to visualize the amount of work
that’s getting done.

Read: A beginner's guide to Kanban boards

Scrum

Scrum is a common Agile methodology for small teams and also involves sprints. The team is
led by a Scrum master whose main job is to clear all obstacles for others executing the day-to-
day work.

Scrum teams meet daily to discuss active tasks, roadblocks, and anything else that may affect the
development team.

 Sprint planning: This event kicks off the sprint. Sprint planning outlines what can be
delivered in a sprint (and how).
 Sprint retrospective: This recurring meeting acts as a sprint review—to iterate on
learnings from a previous sprint that will improve and streamline the next one.

Extreme Programming (XP)

Typically used in software development, Extreme Programming (XP) is an Agile framework that
outlines values that will allow your team to work together more effectively.

The five values of XP include:

 Communication
 Simplicity
 Feedback
 Courage
  Respect

Similar to daily Scrum standups, there are regular releases and iterations, yet XP is much more
technical in its approach. If your dev team needs to quickly release and respond to customer
requests, XP focuses on the “how” it will get done.

Adaptive Project Framework (APF)

The Adaptive Project Framework, also known as Adaptive Project Management (APM) grew
from the idea that unknown factors can show up at any time during a project. This technique is
mainly used for IT projects where more traditional project management techniques don’t apply.

This framework is based on the idea that project resources can change at any time. For example,
budgets can change, timelines can shift, or team members working on the project may transition
to different teams. APF focuses on the resources that a project has, as opposed to the resources a
project needs.

Extreme Project Management (XPM)

This type of project management is often used for very complex projects with a high level of
uncertainty. This approach involves constantly adapting processes until they lead to the desired
result. This type of project involves many spontaneous changes and it’s normal for teams to
switch strategies from one week to the next.

XPM requires a lot of flexibility. This is one of the reasons why each sprint is short—only a few
weeks maximum. This methodology allows for frequent changes, trial-and-error approaches to
problems, and many iterations of self-correction.

Read: Understanding the iterative process, with examples

Adaptive Software Development (ASD)

This Agile methodology enables teams to quickly adapt to changing requirements. The main
focus of this process is continuous adaptation. The phases of this project type—speculate,
collaborate, and learn—allow for continuous learning as the project progresses.

It’s not uncommon for teams running ASD to be in all three phases of ASD at once. Because of
its non-linear structure, it’s common for the phases to overlap. Because of the fluidity of this type
of management, there’s a higher likelihood that the constant repetition of the three phases helps
team members identify and solve problems much quicker than standard project management
methods.

Dynamic Systems Development Method (DSDM)

The Dynamic Systems Development Method is an Agile method that focuses on a full project
lifecycle. Because of this, DSDM has a more rigorous structure and foundation, unlike other
Agile methods.

There are four main phases of DSDM:

 Feasibility and business study

 Functional mode or prototype iteration
 Design and build iteration
 Implementation

Feature Driven Development (FDD)

Feature Driven Development blends different Agile best practices. While still an iterative
method of project management, this model focuses more on the exact features of a software that
the team is working to develop. Feature-driven development relies heavily on customer input, as
the features the team prioritizes are the features that the customers need.

This model also allows teams to update projects frequently. If there is an error, it's quick to cycle
through and implement a fix as the phases of this framework are constantly moving.

Read: Waterfall vs. Agile vs. Kanban vs. Scrum: What's the difference?

Organize Agile processes with Asana

You’ll often hear software development teams refer to the Agile process—but any team can run
Agile. If you’re looking for a more flexible project management framework, try Agile.

What is functional testing?

Functional testing compares actual outputs against expected behaviors. This provides a clearer
overall picture than testing individual modules in isolation. Interactions between modules are
frequently the points where errors occur. Functional testing often includes testing portions of
the underlying code.

There are many types of functional testing:

 Unit testing (which can also be used for non-functional testing)

 Integration testing
 User acceptance testing
 Closed-box testing

What is non-functional testing?

Non-functional testing assesses application properties that aren’t critical to functionality but
contribute to the end-user experience. Performance and reliability under load aren’t functional
components of a software system but can certainly make or break the user experience.
Something that fails a non-functional test doesn’t always cause an issue that users would notice,
but it can indicate a problem in the system — especially at scale.

There are many types of non-functional tests:

 Performance testing
 Load testing
 Usability testing
 Security testing
Types of environments

Before we delve deeper into test environments, we will first discuss the types of environments
that precede and follow test environments. In this context, environments refer to the server
location of the application or software, which are divided according to the state of the software.

Generally speaking, there are four types of environments in software development:

 Development
  Testing
 Staging
 Production

We will briefly go through each of these environments to better understand how they are linked
to distinct stages in the release process.

Development environment

As the name suggests, this is where the development of the software takes place. It is the first
environment where developers write the first lines of code and do all the code updates.

This environment usually consists of a server that is shared by several developers working
together on the same project.

Therefore, when multiple developers are involved, a developer would have a copy of the source
code on their own machine and then changes are submitted to the repository which are then
integrated into the trunk or branch.

A number of preliminary testing takes place at this stage before moving on to the next stages.

For example, if developers have adopted a continuous integration methodology for their software
development process then several changes daily would be committed to the trunk.

Testing environment

The testing environment allows QA engineers to test new and changed code whether via
automated or non-automated techniques.

Development environments are ever-changing as developers keep adding new functionalities

which makes it difficult for QA teams to run time-consuming tests so a testing environment is
where they can execute more complex and time-consuming tests.

The code at this stage usually goes through more than one QA environment where unit tests are
first conducted and the code is moved to further test environments.

Thus, you can either run tests one after the other or you can create several testing environments
that allow for parallel testing to take place, depending on the sophistication of your testing
environment.

More details about the different types of software tests will be discussed in the next sections.

Nonetheless, the focus here is testing individual components rather than the entire application, to
check the compatibility between old and new code, the system’s performance and so on.
If there is a test failure, the faulty code can be removed in this environment. Thus, testers can
ensure the quality of the code by finding any bugs and reviewing all bug fixes. However, if all
tests pass, the test environment can automatically move the code to the next deployment
environment.

Staging environment

This environment is a nearly exact replica of the production environment so it seeks to mirror an
actual production environment as closely as possible to ensure the software works correctly.

The staging environment is often restricted to a small number of selected users and so it is
limited to certain IPs and developer teams.

The purpose of this environment is to test on a near-production level but in a non-production

environment to verify that the application will behave correctly after deployment. Thus, it
represents a safe space away from the public eye to make sure everything works as expected; it is
kept invisible from end-users.

The focus here is to test the application or software as a whole. In other words, staging
environments are where you can conduct tests to ensure that no problems come up in production
and limit negative impact on users there so that when the software is deployed to the production
environment, there will be fewer errors to fix.

Examples of the kind of test that can be run in this environment include smoke testing and in
particular load testing since it can be difficult to replicate high volumes of traffic in a staging
environment to test the software or application under stress.

However, keep in mind that a staging environment is not meant to be a substitute for a real-world
production environment.

To ensure your product works as it should, you need both a testing and staging environment,
where the testing environment makes sure that every component does its job while the staging
environment ensures that your software would behave correctly in an environment almost
exactly the same as production.

While you can run many tests in a staging environment, the best way to truly determine how a
feature performs is to test it on users in real-time, for example, through testing in production.

Production environment

This is where the software is produced and is running on a production server. It has officially
gone live to real users.

When deploying a new release to production, rather than immediately deploying to all users, the
release can be deployed in phases to a segment of your users first to see how it performs to catch
and fix any additional bugs before deploying to the rest of your users.
In other words, just because you’re in the production environment, it doesn’t mean tests have to
end here. You can and should still be testing in production. This can be done with the help of
feature flags, which allow you to safely test in production on a pre-selected number of users.

Now that we’ve covered the main environments a software progresses through in its lifecycle,
we will turn back to test environments and the type of testing that can be conducted in that
particular environment.

3) UAT — User Acceptance Test

After developers finish developing the app and pass all the internal testings, an application is sent
to the client for testing on end-user experience and overall app functionality.

The client can invite a small group of public users to be internal testers. Both Apple and Google
provide tools to let registered testers test on the pre-launch apps to gather user comments and see
if any potential bugs. The testers can open the testing app through TestFlight for iOS app and
Play Store for Android app.

Defect Management Tools

Defect management tools are the application software or web applications in which we record
the defect details and assign it to the developers for fixing the defects. Popularly used Defect
management tools are Quality Center, JIRA, Bugzilla, Scarab etc.

Severity:

Severity is the amount of impact what a defect can make on the application.
Ex: Mails are not sent from a Mail Server application. Here the Its a very “Severe” Defect since
the main functionality of the mail server is to send mails.

Priority:

Priority is given by developers or managers for fixing a defect based on their severity.

Ex: Mails are not sent from a Mail Server application. Here the Defect needs to Highly
“prioritized” and fixed.

Categories of Defects

1. Functional
2. Non Functional

Functional Defects

 Wrong : The software does something that the product specifications says it shouldn’t do.
 Missing : The software doesn’t do something that the product specification says it should do.
 Extra : The software does something that the product specification doesn’t mention.
Non Functional Defects

The defects which is difficult to understand, hard to use, slow etc.

Causes of Defects

 User gives wrong or incomplete requirements.

 Analyst interprets requirements incorrectly.
 Requirements are not recorded correctly.
 Incorrect design.
 Error in coding.
 Data entry error.
 Mistake in error correction.

 Defect classification:

Defect classification is nothing but the process of assigning priorities to the defects found while
testing based on their impacts.

Usually there are several Classification methods used in difference companies.

Below given classification will help to understand the classification:

P5: – Blocker Very high priority defect which is a “show stopper”. Application cannot be tester
further until this defect is fixed. Application also cannot be released once this issue is fixed.

Ex: not able to send any mail from the mail server application.

P4 – Critical: Not a showstopper but still affects the important area of the application.

A possible work around may exist which may not be helpful all the time.

 Regression testing: Tests a software application or system to ensure that changes (such
as bug fixes, enhancements, or new features) do not cause unintended side effects or
regression errors in previously working functionality. It involves rerunning once-
executed test cases to ensure they still pass after the changes are made.
 Retesting: on the other hand, retesting is the process of testing a previously failed test
case after its defects have been fixed. The retesting aims to confirm that the defects/bugs
have been fixed and that the affected functionality works as expected.

Retesting vs Regression Testing: Key Differences

Retesting Regression Testing

Retesting has tests explicitly designed to

check whether known bugs have been Regression testing isn’t targeted testing for known defects.
fixed.

Retesting does not focus on the previous

Regression testing is change-oriented and mainly aims to
version’s functionality. Instead, it aims to
check whether the previous versions’ functionality is
check whether functionality has been
maintained following a change/update to the application.
restored following a bug fix.

Automation is prevalent for regression testing. Manual

testing every time a change or update is made to an
Since retesting checks for a specific defect,
application would be very irrational. Automation is far more
it can’t be automated.
complementary to carrying out blanket tests for unintended
bugs.

Retesting doesn’t have to be a part of the

Regression testing is the norm and is always a part of the
testing process unless a bug is found and
testing process. Every time the application’s code is altered,
corrected; Therefore, retesting is not a
it is good practice to perform regression testing.
guaranteed part of the testing process.

A higher priority is applied to retesting Regression testing has a lower priority than Retesting since
since this testing focuses on fixing known it simply conducts a sweep of the application to check for
defects. potential unanticipated defects.

Regression testing often explores large parts of the

Since only a certain defect is explored in
application to uncover bugs and can be more time-
retesting it is far less time-consuming.
consuming than retesting.

What is an API?

An API, or Application Programming Interface, is a set of rules that define how applications can
communicate with each other. A client makes an HTTP request to an API at an endpoint which it
has access to. The API validates the request and passes the request to the destination server or
program. The server sends a response back, first through the API, which then transfers it back to
the client. The API provides security by decoupling the consuming application from the
infrastructure providing the service. Once an API service and a client exchange authentication
keys, they communicate through the API, meaning they don't have full access to each other, but
enough information can be passed securely to get work done.

A client can issue certain kinds of HTTP protocol requests (or HTTP "verbs"), of which there are
four main types:

 GET - This request reads information from a record in the database.

 PUT- This request changes a record's information in the database.
 POST - This request creates a new record in the database.
 DELETE - This request removes a record from the database.

Technically, the above describes web API usage, which is another reason APIs and web services
get mixed up. APIs can exist outside of the web, however, and have since computers were first
connected together. The important distinction is that APIs are used to link applications, and
while today that is usually done via HTTP or HTTPS, it wasn't always this way.

What are web services?

According to the W3C, a Web service is a software system designed to support interoperable
machine-to-machine interaction over a network. It has an interface described in a machine-
processable format (specifically WSDL). Other systems interact with the Web service in a
manner prescribed by its description using SOAP messages, typically conveyed using HTTP
with an XML serialization in conjunction with other Web-related standards.

Web services use SOAP and XML to allow communication across different programming
languages and different applications across HTTP. A SOAP message is just XML sent between
client and server. This was an open source solution (see Apache Axis for XML-RPC, for
example), to a problem in the early days of the Internet of exchanging data and messaging
between newly connected systems.

Each SOAP document needs to have a root element known as the <Envelope> element, the first
element in an XML document. The envelope element contains the header and the message body.
The header contains the routing data which tells the XML document to which client it needs to
be sent to, while the body will contain the message. But how does the client know where the web
service lives?