Importance of Daily Scrum Meeting and Sprint Retrospective

Importance of Daily Scrum Meeting

What is a Daily Scrum Meeting?

A Scrum meeting is usually held for Projects that are focusing on Agile Development or a company that is adopted for Scrum practices. Daily Scrum is a meeting that is held every working day, usually it scheduled in the morning and will last for maximum of 15 minutes. It is time-boxed to 15 minutes to keep the discussion short and to discuss only the important.

The Daily Scrum meeting is basically a status update. All the members of the team needs to participate in this meeting including the Product Owner, Scrum Master plus the team.

This meeting is beneficial for the following reasons:

• Building the trust between the team members
• Check the sprint is on track and to get to know whether there are road blocks or impediments to achieve the final sprint goal
• Getting the chance to speak and express your ideas in case someone is having impediments
• Helps you to plan ahead of your tasks.

In this meeting everyone needs answer the following questions:

• What tasks did you do yesterday?
• What tasks are you planning to do today?
• What are the impediments you are facing, if you have any?

This meeting improves the team work, and the individual commitment within the team. 

Importance of Sprint Retrospective

The Sprint Retrospective is held at the end of the sprint, basically after the sprint review and before the start of the next Sprint Planning. This meeting can last for 2 or 3 hours depending on the number of team members and the complexity of the things that will be discussed. This meeting is scheduled by the Scrum Master and in some companies there will be one internal retrospective and  the actual retrospective. In the Internal Retrospective, the Scrum Master and Team will join and discuss all what happened in the sprint in detail and find solutions to problems if there were any. However the Actual Retrospective will be held with the Product Owner, Scrum Master and Team and usually will be limited to discussing the important points. 

During the Sprint Retrospective the team discusses the following:

What went well in the Sprint?

What didn't go well in the Sprint?

What can be improved?

What are the actions that will be taken to improve?

This meeting will help to improve the trust between the team, compliment each other for their hard work, Help out each other who was having impediments and to ensure that everybody is part of a team and no one is alone. 

This meeting will improve the quality of the product as improvements are discussed and the actions are noted to be taken, and will be practiced from next Sprint on wards. 

How to do Regression Testing in a SCRUM Project?

What is Regression Testing?

In simple words regression testing is testing again what has already been tested. This testing is done when a modification, code changes or a new functionality added to the system. We do this testing to ensure that the modification will not affect the existing functionality which was perfectly working fine earlier.

When to do Regression Testing?

Whenever a modification is done, it is not feasible to do regression testing. So we have to come up with a plan. If we follow agile we can break several tasks for regression within the Sprint and we can carry out regression testing based on the milestones defined within the sprint. (Eg: Milestones: A date when a specific functionality or two being released and tested). This will ensure the existing functions are working as expected despite there are modification done time to time. If Waterfall once a modification is done to an existing functionality , better to do regression testing for that affecting module only.

You will have to run through all the test cases that's been executed so far which is related to that module and do a high-level testing based on those test cases.

Some Regression Testing Examples (When we need to do regression testing?)

1. When new functionality is added to the system
2. When there is a Change Request
3. When there is a modification in code

However, it is up to the team to plan the regression testing properly without doing it all the time.

I have noticed some teams doing regression testing at the end of the UAT cycle saying they are covering all the end to end test cases. However, it is not how the way it should be done. The testing you do after an UAT cycle which caters end to end is basically system testing.

However different teams follow different methodologies and they have different definitions for these testing approaches. This way I mentioned is what I practiced for a long period.

How to write a Test Scenario?

What is a Test Scenario?

According to my understanding, one functionality can have many Test Scenarios and one Test Scenario can have many test cases. We are writing test scenarios or keeping track of test scenarios because it is an definite aid for our End to end testing. For end to end testing we cannot be executing all the test cases, so we have a set of test scenarios covering all the functionalities in a high level way.

How to prepare Test Scenarios?

Go through the functional spec or the backlog item and determine all the use cases or basically high level scenarios that you have to test. Basically you figure out these first and narrow down the test scenarios to test cases.

Example of How to come up with Test Scenarios for a particular functionality?

Assume the functionality you have to test is purchasing Unit trust which can be Lump sum or Monthly and which can be paid using different payment methods like Cash, SRS or CPF? Minimum amount for purchasing is $1000. Purchased funds are visible to customer.

So basically you can come up with following test scenarios:

• Purchase Lump Sum unit trust
• Purchase Monthly unit trust
• Purchase both monthly and Lump sum unit trust together
• Purchase unit trust with different payment methods
• Can't purchase due to Account having not sufficient funds

You can derive test cases as the following:

• Verify Lump Sum field only accepts numeric
• Verify Lump Sum field minimum should accept $1000
• Verify Monthly field only accepts numeric
• Verify Monthly field minimum should accept $1000
• Verify when Lump Sum unit trust is purchased, it is displayed to customer
• Verify when Monthly unit trust is purchased, it is displayed to customer 
• Verify the records in backend whether purchase successful
• Verify pay with Cash
• Verify pay with CPF
• Verify pay with SRS
• Verify pay with Cash/ CPF/ SRS when customer don't have the relevant account
• Verify the error message displayed when customer don't have sufficient funds
• Verify purchasing unsuccessful screen

Hope this article helps to identify the differences between Test scenario and Test case.

How I practiced Scrum as a QA member?

The Scrum Process I followed

First of all the client is going to create a Product Backlog using Visual Studio Team Foundation Server. The Product Backlog includes all the Backlog items that should be implemented. Backlog item is a specific user story which includes the acceptance criteria for that particular user stories. Like that 100+ backlog items will be there in the Product Backlog.

Prioritization of Product Backlog Items 

The product owner or client will prioritize the backlog items based on the urgency of implementation. Once the backlog items are prioritized the Scrum Master will take several prioritized backlog items to a Sprint. 

What is a Sprint?

A sprint usually will be timed for one month or less than a month. I followed 21 working days Sprint. At the end of a Sprint an usable and potentially releasable product will be released to the Product owner or client. This product we create is incremental and iterative. It will take a few more sprints to complete the Product with all the functionalities yet each Sprint delivers a workable product to customer. A new sprint will start immediately after a Sprint is finished.

Task Breakdown and Task Estimation

The Scrum Master will assign prioritized backlog items for each sprint. Then the team as a whole will divide tasks for each backlog items. Each backlog item will have 2 or 3 development tasks and one QA task. Then the developers will be estimating the hours for each development task using planning poker technique also the QA task will be estimated by QA members in the team using the same planning poker technique. 

Note : This task breakdown and task estimation is done on the Day 1 of the Sprint. 

Buffer time and additional QA tasks per Sprint

Additionally to the tasks breakdown for each backlog item that are taken into the sprint, the team will create few more tasks for QA. Eg: Performance testing task, Integration testing task, Regression Testing task, Automation Testing Task, Test case Creation Task and Test case Review task. Also developers will have their own common tasks created. All these tasks will be estimated using planning poker technique. Usually there will be one internal demo task, Sprint Review task and Sprint Retrospective task included within the sprint. 

Usually team decides how much buffer time needs to be included within a sprint because we never know what will go wrong within a sprint. Buffer time will usually be 1 or 2 days within a Sprint.

What is Sprint Retrospective?

This meeting is normally hosted by Scrum Master. It usually takes place after the Sprint Review and before the next Sprint starts. During the Sprint Retrospective, the team discusses:

• What went well in the Sprint?
• What could be improved?
• What will we commit to improve in the next Sprint?

What is Daily Scrum Meeting?

The Scrum Master, the team and the Product Owner usually sits for this Daily Scrum Meeting. 

During the daily scrum, each team member answers the following three questions:

What did you do yesterday?

• What will you do today?
• Are there any impediments in your way?
• The impediments will be discussed offline after the Scrum meeting.

If any questions happy to answer more!

Facebook as a Federated Identity Provider in WSO2 Identity Server

Who will not like to use one username and password for all their logins? Today it is not necessary to memorize lot of usernames and passwords to login to different applications. Most of the applications/websites support Facebook/Google/Windows Live authentication so people can easily login to different applications from their Google authentication credentials or may be their Facebook credentials or may be their Windows Live credentials.

In this blog post my aim is to cover up how to login to an application using your Facebook credentials with WSO2 Identity Server.

Prerequsities :

Download WSO2 Identity Server 5.1.0 

Steps :

1. Configuring the Facebook App

2. Configuring the travelocity SSO sample

3. Configuring Identity Provider

4. Configuring Service Provider

5. Configuring Claim Mappings for Facebook

Configuring the Facebook App

Follow [1] to configure the Facebook App and get the App ID and secret generated for the application

[1]https://docs.wso2.com/display/IS500/Logging+into+the+Identity+Server+using+Facebook+Credentials#LoggingintotheIdentityServerusingFacebookCredentials-ConfiguringtheFacebookapp

Configure the travelocity SSO Sample

To obtain and configure the single sign-on sample, follow the steps below :

1. You can check out the repository of the SSO sample from GitHub. - https://github.com/wso2/product-is/tree/master/modules/samples/sso 

2. In your command line, navigate to <SAMPLE_HOME>/sso in the folder you checked out and build the sample using mvn clean install. You must have Apache Maven installed to do this.

After successfully building the sample, a .war file named travelocity.com can be found inside the <HOME>/sso/SSOAgentSample/ target folder. Deploy this sample web app on a web container. To do this, use the Apache Tomcat server.

3. Use the following steps to deploy the web app in the web container:

•   Stop the Apache Tomcat server if it is already running.
•   Copy the travelocity.war file to the <TOMCAT_HOME>/webapps folder.
•   Start the Apache Tomcat server. 

Configure Identity Provider

To configure Facebook as the Identity Provider, you have to Log into Identity Server, and in the main tab in the Identity Providers section, click Add

Provide a "Identity Provider Name" and Expand Federated Authenticators > Facebook Configuration and give the App ID and App secret of your Facebook application. User Information fields are some of the claims that are supported by Facebook and you should map them with Identity Server claims later on for Facebook authentication. Claim mappings will be done in further steps

Make sure to Tick both the check boxes to enable the Facebook authenticator.

Configure Service Provider

Go to Service Provider > Add, and create a service provider to register the travelocity application.  Give "travelocity.com" as the Service Provider Name and expand Inbound Authentication Configuration > SAML2 Web SSO Configuration and fill the following details :

Issuer : travelocity.com

Assertion Consumer URLs : http://localhost:8080/travelocity.com/home.jsp

Enable Response Signing

Enable Single Logout

Tick Enable Attribute Profile and Include Attributes in Response Always

Click on Update to save the changes and you will be directed back to the service provider page. Here expand Local & Outbound Authentication Configuration and select Federated Authentication radio button and select "Facebook" as the IDP. Save all the changes.

Configure Claim Mappings for Facebook

Go to the Identity Provider created for Facebook and expand Claim Configuration > Basic Claim Configuration

• Select Define Custom Claim Dialect
• Click Add Claim Mapping

Here Facebook has different attributes/claims that are supported to retrieve all the public information of the user. So these claims should be mapped with any Local Claim URI that is supported by WSO2 Identity server.

Some of the Facebook Supported Claims :

• id
• email
• name
• first_name
• last_name
• link
• gender
• locale
• age_range

Now you have to configure the requested claims for travelocity.com. Go to the Service Provider created for travelocity.com and expand the Claim Configuration.

Click "Add Claim URI" for Requested Claims, Here you should add the claims you mapped in the Identity Provider claim configuration. 

Select Subject Claim URI as email (To use email as the Subject Claim URI you have to Enable Email authentication. Please follow [2] )

[2] -http://nadeeshameegoda.blogspot.com/2015/07/how-to-enable-email-as-username-for.html

Now the configurations are done. To check how this works, access http://localhost:8080/travelocity.com

You will be directed to the travelocity application. When you click on to Login with SAML, you would be directed to Facebook authentication. Enter your Facebook credentials and log into the application.

How to Configure WSO2 Identity Server's Travelocity Sample Application in Tenant Domain

In this blog post my aim is to cover how to register the travelocity application in tenant domain.

Prerequsities :

Download WSO2 Identity Server 5.1.0 

Steps to Follow :

1. Configure the travelocity SSO web application
2. Configure the Service Provider in Tenant Domain
3. Configuring the travelocity SSO application properties file
4. Running the Sample

Configure the travelocity SSO web application

 

To obtain and configure the single sign-on sample, follow the steps below.

1. You can check out the repository of the SSO sample from GitHub. - https://github.com/wso2/product-is/tree/master/modules/samples/sso 
2. In your command line, navigate to <SAMPLE_HOME>/sso in the folder you checked out and build the sample using mvn clean install. You must have Apache Maven installed to do this.
3.  After successfully building the sample, a .war file named travelocity.com can be found inside the <HOME>/sso/SSOAgentSample/ target folder. Deploy this sample web app on a web container. To do this, use the Apache Tomcat server.
4. Use the following steps to deploy the web app in the web container:
       Stop the Apache Tomcat server if it is already running.
       Copy the travelocity.war file to the <TOMCAT_HOME>/webapps folder.
       Start the Apache Tomcat server. 

Configure the Service Provider in Tenant Domain 

The next step is to configure travelocity.com as service provider in tenant domain. For this you have to first create tenant domain using WSO2 Identity Server

Steps to Create Tenant Domain  :

1.Login to Identity Server with admin/admin credentials
2.Go to Configure Tab > Add New Tenant

Steps to Create the Service Provider in Tenant Domain :

1.Login to Identity Server with the tenant admin credentials ( tenant@wso2.com)

2.Next navigate to the Main menu and click Add under Service Provider 

3.Expand the Inbound Authentication Configuration section and then expand SAML2 Web SSO Configuration.  

 Issuer : travelocity.com
 Assertion Consumer URL : http://localhost:8080/travelocity.com/home.jsp
 Enable Response Signing
 Enable Single Logout 

4.Save the Service Provider Configuration.

5.Next you have to export the public certificate of the private key used at webapp side to sign the SAML Authentication Request. Following command can be used to export it.

keytool -export -alias travelocity -file travelocity -keystore <path to wso2carbon.jks> '''

6.Import the above exported public certificate to the tenant key store of the internal IDP, identity server as below. 

 7. After the import it will be listed as the following :

8. Edit the Service Provider Configuration and select "travelocity" as the Certificate Alias.

9. The configurations are mostly done to get the SSO scenario work with the webapp. We need to export the tenant public certificate to be imported to the trust store at webapp side. This is in order to verify the SAML Response/Assertion signed signature at the webapp side. We can export the certificate as below from the UI, using public key link.

 10. The exported key needs to be imported to webapp truststore(in this case wso2carbon.jks located inside the {Tomcat_Home}/webapps/travelocity.com/WEB_INF/classes

 keytool -import -alias <The given alias name. Here travel.com> -file <path to downloaded public certificate> -keystore <path to trust store of webapp. Here the wso2carbon.jks file> 

 Configuring the travelocity SSO application properties file

Now you have to change the following properties in the travelocity.properties file located in {Tomcat_Home}/webapps/travelocity.com/WEB_INF/classes

Approach 1 :

 
SAML2.SPEntityId=travelocity.com@wso2.com (Here you have to add the Service Provider issuer name appended with the tenant domain)

IdPPublicCertAlias=travel.com (This is the alias you gave when executing Step 10 in Configuring the Service Provider to import the tenant public certificate   to web app)

 Approach 2 :

Apart from the above their is another way that you can specify the tenant domain in travelocity properties file. You can try the above mentioned way, or either the below mentioned way. You can pass the tenant domain as QueryParams as follows:

Give the SAML2.SPEntityID = travelocity.com

Uncomment the following in the propertied file :

QueryParams=tenantDomain=wso2.co

IdPPublicCertAlias=travel.com


Now you can test the SSO with travelocity application and login with tenant domain.

Running the Sample

 

Visit http://localhost:8080/travelocity.com . You are directed to the following page:

Since you need to use SAML2 for this sample, click the first link, i.e., Click here to login with SAML from Identity Server. You are redirected to the Identity Server for authentication.

 Enter Tenant Admin credentials and you'd be able to successfully log in.

  
 

Configuring Single Sign-on with SAML 2.0 for WSO2 Dashboard Server 2.0

The Actual Configurations for SSO and How to get it Working..

 

Prerequisites :

 

Identity Server 5.1.0 (Download : http://wso2.com/products/identity-server/)
Dashboard Server 2.0.0 (Download : https://github.com/wso2/product-ds/releases/tag/v2.0.0-beta)

Configurations for both DS and IS to point to a common User database/store.

1. Create a MySQL database (e.g., ustore) and run the <DS_HOME>/dbscripts/mysql.sql script on it to create the required tables.
2.Open <DS_HOME>/repository/conf/datasources/master-datasources.xml file and add the datasource configuration for the database that you use for the shared user store and user management information. For example,

3. Open <DS_HOME>/repository/conf/user-mgt.xml file and point to jdbc/ustore.
<Property name="dataSource">jdbc/ustore</Property>
Note - DS will have the the jdbc user store as the default user store. So in the same file the jdbcUserStoreManager will be uncommented. Leave it as it is.

4.Open <IS_HOME>/repository/conf/datasources/master-datasources.xml file and add the USTORE datasource that you added to DS listed above. So now both IS and DS will point to the same database.

5. Open <IS_HOME>/repository/conf/user-mgt.xml and point to jdbc/ustore
<Property name="dataSource">jdbc/ustore</Property>
Note - IS will have the ldap user store as the default user store. So you have to comment out the ldap configuration and uncomment the jdbc user store in the same file. So both DS and IS will be accessing one common user store.

6. Open <IS_HOME>/repository/conf/identity/embedded-ldap.xml and disable the embedded ldap by setting  <Property name="enable">false</Property> within <EmbeddedLDAP> tags.

Now Both DS and IS will be pointing to one common user store..

7. Remember to copy the database driver into  <DS_HOME>/repository/components/lib> and <IS_HOME>/repository/components/lib and restart the servers

Now Let's Register the Dashboard Server portal as Service Providers in IS

1. Start the IS pack
2. Go to IS Management Console > Main > Service Providers > Add
3. Give a unique name for service provider and click Register
4. Click on Inbound Authentication Configuration > SAML2 Web SSO Configuration > Configure
5. Fill on the details as follows for the DS portal

Note - Assertion Consumer URL has my local/machine ip address. Configure it with your correct ip address and my Dashboard Server is running on port 9444 which I have stated the offset as 1. This will be done in the future steps.

Now the Service Provider is successfully registered.

Now Let's Do the Configurations for Dashboard Server to Enable SSO with WSO2 Identity Server

 

1. Open <DS_HOME>/repository/conf/carbon.xml and change the offset to 1
2. Open <DS_HOME>/repository/deployment/server/jaggeryapps/portal/configs/designer.json

"authentication": {
    "activeMethod": "sso",
    "methods": {
      "sso": {
        "attributes": {
          "issuer": "ues",
          "identityProviderURL": "https://10.100.7.57:9443/samlsso",
          "responseSigningEnabled": "true",
          "acs": "https://10.100.7.57:9443/portal/acs",
          "identityAlias": "wso2carbon",
          "useTenantKey": false
        }
      },
      "basic": {
        "attributes": {}
      }
    }
  }

Here the identityProviderURL will point to the IS and the issuer is given as "ues" since when we were adding the service provider for the Dashboard Portal we gave the issuer as "ues". Both should be the same.

Also "activeMethod" should be changed from "basic" to "sso"
"acs" is the Dashboard Server portal acs URL

Now We are Done with the Configurations!!

Start the DS server and Open up a Browser. Hit the portal URL (https://10.100.7.57:9444/portal). You should be directed to the IS login. Enter admin/admin username/password and sign in.

Following is the IS login page that you will be directed to :