What are different processes involved in scrum development?

We have been witnessing the milestones achieved in the field of software engineering with the help of the scrum development process regarding the development of the agile projects. There is no doubt regarding the efficiency of the scrum development process in the terms of agility. 

It supports all the principles as stated by the agile manifesto for all the development methodologies and processes falling under the category of the agile software development processes. 

Initially the scrum approach to development was considered to be a holistic but eventually in by the year of 1995 it achieved its present form and was officially termed as the “SCRUM”. 

Scrum Development Cycle

The scrum methodology consists of various stages and processes that we are going to discuss in this article. The scrum development cycle is constituted of the below mentioned processes:

1. Creation of the product back log
2. Creation of the sprint back log
3. Sprint
4. Delivery of a shippable working increment of the software system or application.

- The product back log can be thought of as an ordered list of the requirements and specifications of the software product or the system that is to be developed and its creation is the responsibility of the product owner. 

- The product owner orders some product back log items and these items only are mentioned in the product back log.

- The product owner may order these product back log items based on any one of the following criteria:

1. Risk
2. Business value
3. Date needed
4. Dependencies and so on.

What is Product Back Log?

- The product back log is a list that is open to every one and all are free to edit it but, for any kind of changes and ordering the items, only the product owner is only held responsible. 

- Apart from the requirements, the rough estimates of the development efforts and business values are found in the product back log. 

- All these values appear in the back log but in the form of some story points developed by the means of some rounded Fibonacci sequence.

- With the help of these estimates the product owner is able to gauge the time line and influence the ordering of the back log items. 

- Contrary to all this, the efforts required for completing each back log item is estimated by the development team. 

What is Sprint Back Log?

- It can be thought of as a list of work or tasks that must be addressed by the development team in the sprint that is to follow. 

- The sprint back log is prepared by obtaining some selective features and stories form the product back log until the sprint includes enough tasks to be accomplished. 

- But while adding the tasks the velocity of the previous sprints should be taken care of by the development team. 

- The stories or the features are broken down in to smaller tasks that up on estimation would not exceed 16 hours of efforts by the development team. 

- This reduces the burden on the development team and helps them understand what is to be done. 

- Rather than assigning the tasks on the sprint back log, they are just signed up by the development team as required for the following sprint and according to the priority and skills of the development team. 

- The working increment that is delivered at the end of the sprint is the sum of all the product back log items that have been completed during that particular sprint and all the other sprints preceding it. 

- It is necessary that the increment is delivered in a working condition and is usable.

Who all are involved in scrum development? What are their roles?

Scrum development process is one of the very famous agile software development processes which is nowadays gaining much popularity with the developers and the programmers. Since its advent it has been proved very effective when it comes to the matters regarding the management of the software system and products development. So many people and professionals are involved with the scrum development process and importance of each of them is so inevitable. 

In this article we will be discussing about all the people involved in the scrum development process. So let us see who all are involved in the scrum development process.

Categories in Scrum

- The people involved in the scrum development process have been divided in to two categories according to the importance of their participation in the development process. -

- Those two categories are namely:

1. The core roles and
2. The ancillary roles

- All the roles falling under the above mentioned two categories are pre defined and have their own unique part to play in the development process. 

Core roles in Scrum

- The core roles in the scrum development process are those who are strongly committed to the development of the software project.

- These roles are only responsible for the primary production of the software product. 

               a) The scrum master

                   b) The product owner

                   c) The Development Team

The Scrum Master

- As the name of the role itself suggests, the scrum master is said to be the in charge of the whole scrum development process.

- It ensures that all the processes are being implemented properly and at the right place thus removing the impediments. 

- He/ she also hold the responsibility for the protection of the development team from disruption and other factors that can falter the spirit of the development team. 

- The impediments are removed to the ability of the team by virtue of which it delivers the goals or deliverable of a sprint or iteration.

- Though all the processes in the scrum development are facilitated by the scrum master he/ she is not to be mistaken for the team leader. 

- It is a kind of role that acts as a buffer i.e., resists the development team from all the influencing distractions and disruptions. 

- He/ she always make it a point to ensure that the scrum processes are put in to right use. 

- The scrum master acts as a police thus enforcing the rules. 

- Overall, the scrum master is responsible for maintaining the focus of the development team on the tasks that are at hand and protect the team from any wrong factors. 

- In most of the cases the role of the scrum master has been characterized as “servant- leader” to represent the dual perspectives of the role.

The Product Owner

- This sub category involves all the stake holders and the business people involved in the development process and production process indirectly. 

- One person known as the product represents the voice of all these people. 

- The product owner holds the responsibility for telling the requirements and demands of the customers and the business people to the development team so that the desired values are delivered to the business.

The Development Team

- The values desired by the business are delivered by none other then the development team. - At the end of each sprint, the deliverable obtained is nothing but a shipped product increment. 

- A typical development team may consist of at the most 10 members who possess skills like self organizing and cross functionality.

Ancillary Roles in Scrum

The ancillary roles consist of the following roles:

1. Stake holders and
2. The managers. 

What is scrum methodology?

When it comes to the agile software development practices, the “scrum” is what that comes to our ears! The scrum development methodology is not new to us, it is something that we have been witnessing over the years in the field of the software engineering. 

This article has been dedicated to the scrum methodology! Scrum is a very vast topic to be discussed in detail in an article of short length! Here in this article we have tried to give you a glimpse of what is scrum methodology actually. 

Evolution of Scrum Methodology

- Scrum being an agile software development is supposed to follow a methodology based up on the iterative and incremental model of development. 

- Over the years the scrum development methodology has made the development and management of the software products and projects. 

- The birth of the software development was seen as an approach towards the commercial production of the software products thus making a remarkable improvement in the flexibility and speed. 

- The cross functionality and self organized teams are considered to be the best ones to perform the scrum development. 

- Initially the scrum development methodology was known as the rugby or the holistic approach to development. 

- The rugby approach was first replaced with the name scrum methodology in the year of 1995 when the a paper describing this methodology was presented in the “business object design and implementation work shop” by the Schwaber and Sutherland. 

- This workshop was conducted as a part of the OOPSLA ’95. Scrum consists of some of predefined roles and methods that regulate the whole development process. 

Roles in Scrum Development

The pre defined roles in the scrum development have been categorized in to two categories as we have discussed below:

1. The Scrum Master: As the role itself suggests this person is responsible for taking the charge of the whole development process.
2. The Product Owner: This role is also self justifying but does not refers to a single person, rather it includes all those people who are to be benefitted by the software product on the terms on which it has been agreed up on.
3. The development team: The scrum development team is one that has the characteristics like cross functionality and self organizing.

Terminology used in Scrum Methodology

Now we shall discuss some terminology of the scrum methodology:

1. Sprint: Like so many cells together form a tissue, similarly many iterations or sprints together make up the sprint development cycle. Like all the other software development processes the sprints or the iterations in the scrum process are time boxed. And also like what happens in all the other agile software development processes, here also a sprint planning meeting is conducted before the starting of the sprint. The features that have to be incorporated in to the software system in a particular sprint are obtained from the product back log.

2. Story time: This is the time spent by the whole team grooming the back logs. The existing block usage efforts and points are estimated during this time thus chalking out  a whole new acceptance criteria for the individual stories. 

3. Daily Scrum: This is a sort of a project meeting that takes during the sprint and is also known as the daily stand up. Certain guidelines are must to be followed in this meeting:

(i)   Meeting should start at the exact time.

(ii) The participation of the core roles is mandatory.

(iii)Meeting should not exceed 15 minutes.

(iv)Meeting should take place at a fixed place every time. 

(v)  Each member must answer the below mentioned 3 questions:

(a)  What have you done?

(b)  What do you plan to do today?

(c)  Do you see any stumbling blocks?

How does a DU path segment play a role in data flow testing?

Whenever you would have came across the topic of data flow testing, you surely would have heard about the term “du path segment” but still not familiar with it! This article if focussed up on the du path segments and what role it has got to play in the data flow testing. 

We will discuss the du path segments under the context of data flow testing and not as a separate topic so that it becomes easy for you to understand. 

The whole process of data flow testing is guided by a control flow graph that apart from just guiding the testing process also helps in rooting out the anomalies present in the data flow. With all the anomalies being already discovered one can now design better path selection strategies taking in to consideration these data flow anomalies. 

There are nine possible anomalies combinations as mentioned below:

1. dd: harmless but suspicious
2. dk: might be a bug
3. du: a normal case
4. kd: a normal situation
5. kk: harmless but might be containing bugs
6. ku: a bug or error
7. ud: not a bug because of re- assignment
8. uk: a normal situation
9. uu: a normal situation

For data flow testing some data object states and usage have been defined as mentioned below:

1.      Defined, initialized, created à d

2.      Killed, undefined, unreleased àk

3.      Used for:

(a)    Calculations à c

(b)   Predictions à p

Terminology associated with Data Flow Testing

Almost all the strategies that are implemented for the data flow testing are structural in nature. There are certain terminologies associated with the data flow testing as stated below:

1. Definition clear path segment
2. Loop free path segment
3. Simple path segment and lastly
4. Du path

What is a DU path Segment?

- DU path segment can be defined as a path segment which is simple and definition clear if and only if the last link or node of the path has a use of the variable x.

Let us take an example to make the concept of du path segment clearer. 

- Suppose a du path for a variable X exists between two nodes namely A and B such that the last link between the two nodes consists of a computational use of the variable X. 

- This path is definition clear and simple. 

- If there exists a node C  at the last but one position that is the path is having a predicate use and the path from the node A to node C is definition clear and does not contain any loop. 

- Several strategies have been defined for carrying out the data flow testing like:

1. ADUP or all du paths strategy
2. AU or all uses strategy
3. APU+ C or all p uses/ some c uses strategy
4. ACU +P or all c uses/ some p uses strategy
5. AD or all definitions strategy
6. APU or all predicate uses strategy
7. ACU or all computational uses strategy

Strategy for DU Path Strategy

We shall describe in detail here only the ADUP or all du paths strategy. 

- This strategy is considered to be one of the most reliable and strongest data flow testing strategy. 

- It involves the use or exercising of all the du paths included in the definition of the variables that have defined to every use of the definition.

- All the du paths suppose to be a strong criterion for testing but it does not involve as many tests as it seems.

- Simultaneously many criterion are satisfied by one test for several definitions and uses of the variables.

What are different data flow testing strategies?

Data flow testing is quite important since you do not want any unreasonable things happen to your data objects which in turn can deviate the whole control flow of your program from the right track. To make a sensible data flow testing you need to use sensible and reliable data flow testing strategies.

This article is all about such data flow testing strategies. 

There are two types of machines that are used by the data flow as mentioned below:

1. Von Neumann machine architecture
2. Multi- instruction, multi- data machines architecture (MIMD)

- Before carrying out the data flow testing, it is good to assume a bug which causes problem in the control flow of the program. 

- It is not compulsory to use the typical data flow graphs, annotated ordinary control graphs can also be used for guiding the data flow testing process. 

- Data flow graph depicts all the directed links and nodes involved in the data flow.

- All the strategies for data flow testing that we are going to discuss are structural in nature and also focus up on the actions taking place on the data objects rather then just focussing on the connectivity of the software program.

Requirements of Data flow testing Strategy

- Data flow link weights are the first requirement of any data flow testing strategy. 

- All these strategies are based up on the selection of the path segments that very well satisfy at least few of the data flow characteristics common to all the data objects. 

- A data flow testing strategy is weaker than another strategy Y if all the test cases present in Y are not included in the X. Then Y is said to be a stronger strategy. 

Important Terminologies

Let us take a look at some important terminologies before moving on to the strategies:

1. Definition clear path segment: It is a path defined with respect to a variable X that consists of various links such that the X is defined only on the first link.
2. Simple path segment: In such a path one of the two nodes are visited twice.
3. Loop free path segment: This path is contrary to the simple path segment in the way that in this path every node is visited once for the maximum.
4. Du path segment: It is a path that is simple and definition clear since its last link consists of a computational use of variable X.

Different Strategies for Data Flow Testing

Below described are the different strategies for the data flow testing:

1. ADUP or all DU paths: This strategy is considered to be the strongest among all the data flow testing strategies. It takes in to account all the du paths that occur in the definitions of all the variables to their every use. This strategy is a strong data flow testing criteria also. Another advantage of this strategy is that one of its tests can satisfy many definitions at a time.
2. AU or all uses strategy: Under this strategy at least one of the definition clear paths from all the definitions of a variable has to be tested or exercised under a test. The task or burden of testing is actually reduced here i.e., the path coverage is cut down to branch coverage.
3. APU + C or all p uses/ some c uses strategy: This strategy covers up at least one definition free path to every predicate use for every definition of the function. If this is not able to over up all the definitions of the variable, then it is recommended that computational use test cases are exercised.
4. ACU + P or all c uses/ some p uses strategy: This strategy is just the opposite of the above strategy.
5. AD or all definitions strategy: It covers only the definition of the variable. 

What are different terminologies used in LoadRunner ?

Application performance testing requirements are divided into scenarios using LoadRunner.
- A scenario defines the events that occur during each testing sessions.
- A scenario defines and controls the number of users to emulate, the actions that they perform, and the machines on which they run their emulations.

Vusers
LoadRunner works by creating virtual users who take the place of real users operating client software. LoadRunner works by creating virtual users who take the place of real users operating client software. Vusers emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of
Vusers.

Vusers Scripts
The actions that a Vuser performs during the scenario are described in a
Vuser script. When you run a scenario, each Vuser executes a Vuser script. Vuser scripts include functions that measure and record the performance of the server during the scenario.

Transactions
Transactions are defined to measure the performance of the server. Transactions measure the time that it takes for the server to respond to tasks submitted by Vusers.

Rendezvous Points
Rendezvous points are inserted into Vuser scripts to emulate heavy user load on the server. Rendezvous points instruct multiple Vusers to perform tasks at exactly the same time.

Controller
LoadRunner Controller is used to manage and maintain your scenarios. Using the Controller, you control all the Vusers in a scenario from a single workstation.

Hosts
The LoadRunner Controller distributes each Vuser in the scenario to a host when the scenario is executed. The host is the machine that executes the Vuser script, enabling the Vuser to emulate the actions of a human user.

Performance Analysis
Vuser scripts include functions that measure and record system performance during load-testing sessions. During a scenario run, you can monitor the network and server resources. Following a scenario run, you can view performance analysis data in reports and graphs.