Sprint in Agile methodology

A sprint, in Agile software development, is a set period of time during which specific work has to be completed and made ready for review.

The idea of having a time box is to ensure that immediately after the sprint, they can retrospect and adapt to make improvements.

This ability to inspect and adapt is the most critical goal of a sprint that allows the team to inspect the product increment iteratively and also improve how they work together as a team.

Few Things about Sprint :

  • Every Sprint is of same duration
  • Every Sprint is four weeks or less in duration
  • There are no breaks between two Sprints
  • The intention of every Sprint is "Potentially Shippable" deliverable
  • All meetings/ceremonies are time boxed
  • Every Sprint starts with Sprint Planning Meeting
Following are the typical ceremonies of scrum:
  • Backlog Grooming
  • Sprint planning
  • Daily Standup
  • Sprint Review
  • Sprint Retrospective

Sprint Planning / Sprint 0 (zero)

Sprint Planning takes place at the beginning of an iteration or interval and the team determines how much work it thinks is possible to be accomplished be the end of the interval.

  • The Sprint Planning Meeting facilitated by Scrum Master
  • The Sprint Planning Meeting is attended by Scrum Master, Product Owner, Dev Team members, Testing Team, and stakeholders
  • The Sprint Planning Meeting produces committed Sprint Backlog
  • No additional stories to be added into Sprint Backlog after the Sprint Planning Meeting (they do add it in between the sprint)
  • Sprint planning should happens after considering availability of employees
  • No story deleted after the Sprint Planning Meeting from Sprint Backlog

Daily standup / Scrum

Daily Scrum takes place every day and is usually a stand up meeting with not more than 10–15 minutes time. The goal here is that the teams exchanges information about ongoing work, identifies synergies or impediments and ideally makes a quick planning for the day. (happens for 30 minutes)

Every day of team has Daily Standup at same time of day, where all the stakeholder are available

The Daily Standup is not a status meeting but information sharing and asking for help meeting

In the Daily Standup every team member answers three things only.
1. What is the issue you are facing
2. How you are planning to mitigate it
3. What is next actionable item for the day.

Sprint Review

Sprint Review meeting is the meeting where the product that was implemented in the interval is demonstrated to the product owner and possible other stakeholders or even people who are interested. This meeting is an important source of feedback about the product.

The Sprint Review Meeting is conducted at last day of Sprint before Demo and Retrospective

The Sprint Review Meeting is for stakeholder feedback on the increment of current increment as well as product

The Sprint Review Meeting is facilitated by Scrum Master

All members of the team attend the Sprint Review Meeting

The Sprint Review Meeting is time boxed in to two hours per week of Sprint duration

Sprint Retrospective

Sprint Retrospective meeting is a team meeting at the end of an iteration which implements the agile principles of reflect and tune. Usually the team identifies what went well and should be strengthened and also what didn’t work and should be removed.

A Retrospective is strictly for the team. Only pigs are allowed, no chickens

In the Retrospective loop back the action items of previous Retrospectives

All team members attend every Retrospective

Client expects only two items, What you have to improve, what you should have done better. (They may not listen even you have some concerns with development team, if the development team drops the code at last day and they will say it is agile process you have to do it (in what universe, i donot understand)

Role of Scrum master

The Scrum Master serves the Product Owner in several ways, including:

Ensuring that goals, scope, and product domain are understood by everyone on the Scrum Team as well as possible;

Finding techniques for effective Product Backlog management;

Helping the Scrum Team understand the need for clear and concise Product Backlog items;

Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;

Scrum master should address the impediments if any and should resolve to mitigate them and associated concerns .

Identify the areas that could have been handled better in the retrospective. The plan should be to create the list ,group and discuss then vote per the priority.

Roles Of Product Owner

The key stakeholder of Scrum Projects is the Product Owner One integral responsibility of the Product Owner is to convey the importance and significance of the Scrum Project to the Scrum Team.

The PO is no one but the representative of the client, the client may not be able to attend these small meeting, so they have created miniatures of them in the form of PO.

In some organization this person is also known as Business Analyst aka BA, he/she is the one who knows the actual intentions of the client. PO gives demo of the sprint product to the client after the Sprint.

  • The PO determines which functionality will be developed
  • The PO determines the priority of what will be developed
  • The PO manages the backlog (the administration of functionality to be developed)
  • The PO discusses with all stakeholders what is needed to create business value
  • The PO accepts the functionality during the sprint review, so it can be delivered to the production environment
  • The Product Owner represents team in Demo
  • The Product Owner is accountable to refine Product Backlog on continuous basis
  • The Product owner do not add or delete items in Sprint Backlog in middle of a Sprint (but this happens)

Testing Team

As I donot know much about Dev team, so I am directly jumping into Testing Team ( I am a tester, the lazy one in the testing team )

Testing team may consist, Team lead, and automation tester, manual tester or same person handle end to end process of a user story.

Testing team will perform below tasks in Sprint.

  • User story analysis
  • Feasibility study of automation
  • Testcase preparation
  • Testcase Review (I hate this part)
  • Automation script Development
  • Automation code review
  • Cross browser/Platform testing
  • Exploratory Testing ( I enjoy this part)
  • Go Live testing

Dynamic method dispatch in Java & Selenium

User story analysis

User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system.

They typically follow a simple template:
As a < type of user >, I want < some feature > so that < I achieve something >.

Most of the time PO writes the user story, people will say anyone can write the user story

Here any one means the people who represent the client (So tester or developer or scrum master cannot write the user story, who is remaining now in scrum team, PO. ha ha ha)

Feasibility study of automation

On automation feasibility study, automation team will decide whether to automate user story or not

Feasibility is decided based on the following factors:
1. The feature is automatable or not with current technology

2. We will decide whether it is possible to automate the user story in this sprint or not.

3. Does user story contains the flakiness or not, if the story has flakiness then tester should write the manual test cases based on this flakiness in a way that User story test cases are split into automation test case and manual test case.

Note : Flakiness is nothing but will the automation passes in all the times (if there is no functionality change)

By splitting the user story onto manual and automation is helpful to write good automation tests, this is the reason why feasibility should be done before writing the testcases

Testcase preparation

Test case preparation is nothing but the combination of test steps to test the user story. User story can have any number of test cases but ideally 2-4 only.

Test cases must be written based in the feasibility study of automation

Testcase Review

Test case review is nothing but the review of your test steps in the test case to check whether you have covered the user story or not.

Peer review: It is done by another tester who hasn’t written those test cases but is familiar with the system under test. The reviewer must have better knowledge than the person who wrote it.

Review by a PO: It is done by PO, who has great knowledge about the requirements and Application.

Automation script Development

In Automation script Development, so called us will start writing the automation test script for the manual test steps, We should use the assertion statement only when a test steps say to verify something otherwise automation tester should not assertion for test steps.

When we write the test script we should make sure, test cases present in the test suite are not related to each other, we should avoid writing the dependent test cases.

We should make sure we are cleaning the mess that we are creating, for example if you are creating a order, end of the script you should remove the order.

When we start writing we should not assume anything like there will be some details present in the application which we can use it

Always your tests should start with scratch and you have to create your test data, so that you test will not fail because of the data issues

Never consider your test case as failed unless the verification point fails, test step failures must not be considered as test failure, only verification failures should be considered as test failures

Always write the method names in legible way, so that when some person reads a method or test name, he should able to understand it.

In agile you should be ready with skeleton code and with dummy locators, when the development team deploys the code, you should be in a position to replace you dummy locators and should be able to execute with minimal change

In actual agile process, development team should give the locators prior to deployment or even before development itself.

In more agile process, development team should only use unique locators throughout the application, for example unique id or some attributes which gives details about the element.

Tester should never push a code without executing multiple times.

I understand your question, when do we need to perform manual testing ?

The answer is never, while writing the automation code, you would be checking the details of an element or a feature for writing the verifications. I hope that itself covers the manual testing.

Automation code review

In this activity, your senior or knowledgeable person in the team reviews the automation code of yours

In most of the organizations the code will be reviewed by seniors, sometime seniors who doesnot have good technical knowledge, we cannot do anything for that. For Code review guideline we have created a separate chapter : Selenium Code review, please do visit and learn.

Cross browser / Platform testing

Cross browser testing means to validate any application on various browsers to ensure that it is working and quality is validated.

Sometimes, you will find scenarios during testing which will occur on one browser but not with another browser.

Reasons behind cross browser testing :
1. To test layout, UI issues on different browsers and browser versions.

2. To test the core functionalities and performance on them.

3. Test the web application on mobile browsers, and check the layout when the orientation of the device is changed

4. To ensure all UI elements are rendering properly, and scripts are executed without any issue

5. Browser incompatibility with OS. Etc.

Browser to be considered for cross browser testing (major ones):
1. Google chrome
2. Firefox
3. Microsoft Edge
4. Safari
5. Internet Explorer

Cross Platform testing

In Cross Platform testing, we will be testing the test script in different operating systems, sometime different version of operating system.

Exploratory Testing

Tester doesn’t refer any of the documented test cases rather he/she is exploring the application with intention to break it.

It might involve going deeper into application, making data combinations which are never thought of and so on. So in this case if you find a bug, you don’t have a test case to refer it.

You should test the parts of the application which are developed only, you should not try to test features which are not developed.

I enjoy doing exploratory testing, we used to get gifts or cookies if we were able to find good bugs as part of exploratory testing (In my first project 2012)

Go-Live testing

Go-Live testing is nothing but client side tester will start testing the application that we gave a sign off on the live/production environment.

This is the scary part, where client escalates the vendor or testing team if t=client finds any bugs on the code, which they have covered in User Story.

Testing and development team should be available when the client perform the Go-Live testing.

Testing and development team should be available when the client perform the Go-Live testing.

Remember this Quote No one remembers when you are right, but no one forgets when you are wrong, I used wear this Quoted t-shirt for my Go-Live testing.

What I hate about this agile

Sometime Product Owner will not have enough knowledge of the feature or the product, so they will add little little things in between, if we question they will say it is Agile process.

Testing team will not have enough time like development team, if the development team does not give information about the feature like locators

Mostly developers influence the PO, if there is minor difference in pixels( 1 px difference) . After five or six times there they have given 5 px difference, Now they will question QA team why there is 5px difference. Bu no one cares when you said there is 1 px difference.

Mostly if you are working as vendors (most of as do, including me ), then your management treats the clients as god, you cannot even oppose them.

If you(tester) and the client representative are from same county then your life will be ruined, but if you have other county guy as client representative, then the attitude not be there

 
Join My Facebook Group
Join Group
 

About Author

Myself KarthiQ, I am the author of this blog, I know ways to write a good article but some how I donot have the skills to make it to reach people, would you like help me to reach more people By sharing this Article in the social media.

Share this Article Facebook
Comment / Suggestion Section
Point our Mistakes and Post Your Suggestions
  • Shalini
    Sorry it was thumbs up icon but when posted encoded to Question mark symbol..
    Reply
    • karthiQ [ admin]
      Hi Shalini,
      We will keep up as long as we have readers like you. Thanks
      Reply
  • Shalini
    Hi KarthiQ,
    
    Very Good, informative and useful blog ya ????
    Keep up the good work ????
    
    Takecare..
    Reply
  • Copyright © CherCher Tech