How we do Scrum!

I’m writing this blog post to share my ideas and experience as tester within a Scrum team. This article will describe you how we define our way of doing things within the scrum frame work.

We need to be open minded and prepare for accept changes to start with scrum. So if you are a beginner to scrum, please be open minded even when you are reading this article.

Start of the sprint, first tasks for the testers should be creating test cases and corresponding test data/test files as soon as possible. And then store those information (test cases, test data/test files) in common location. What we do is we store that information in CVS.

Then testers should present their test cases to developers before complete the development tasks. And also testers should provide information about test files/test data with relevant to those test cases. Then developer could test their own codes against tester’s test cases and test files/test data. By this approach testers get more tested or more quality product to start their testing.This will be the first step towards Test Driven Development. Even though above mentioned approach is not clearly within the scope of TDD, we could adopt to that kind of approaches to drive the team to provide more quality product.

When tester found an issue then he/she should inform the relevant developer via immediate communication channel (verbally or via chat). After that tester writes a very short email to particular developer(s) with sufficient information to recreate or debug the found issue (This is not formal email. Only purpose of this email is providing sufficient information).

Normally we CC this mail to Scrum master and test lead as well. Test lead could a keep track of the issue if it’s necessary. Reporter should follow up the status of the issue with the developer until the issue gets fixed. What we do is we encourage our team members to do more and more pair programming, tester and developer together. This approach is work well for us towards provide quality code. If any of the issues not getting fixed and reporter still thinks issue is valid then, reporter could raise the issue in daily scrum meeting. We could store the bug tracking excel sheet in common location. Then reporter himself/herself can update the excel sheet and keep track of the issues by themselves. Current plan is to store this bug tracking excel sheet as a Google.doc or store in confluence. Then developers also could access the bug list and pick tasks directly from the list.

Purpose of this approach is reduce the waiting time of maintaining the cases in JIRA and increase the self-managed team efforts.

If developers have many issues to fix then, normally scrum master prioritized the issues with idea of the team. If the developers fail to fix all the reported bugs at the end of the sprint, then unresolved issues should report in JIRA at the end of the sprint. Then product owner could plan those JIRA cases to another sprint by considering the business impact of those issues.

After completion of a sprint we don’t need to keep the bug tracking sheet anymore, since at the end of the sprint either all the issues get fixed or rest of the issue are reported in JIRA. So we don’t need the excel sheet anymore.

If we found many blockers during sprint and if we see a risk of completing all the stories within the planned sprint then, best option is reduce the scope of the sprint, drop one or many planned stories. And move those dropped stories to another sprint. Everything we have completed during the sprint should be in deployable status at the end of the sprint, which means all the ‘done’ user stories should be ready for production at the end of the sprint.

We don’t change the sprint duration due to any reason. In scrum what we believe is we never negotiate about the quality of the product and we never change the duration of time boxed items. But we do have the flexibility of changing the scope of the sprint, due to major risks of completing planned to stories within the sprint.

During the sprint demo we present our test execution status. If there are any remaining issues we should present the particular JIRA cases which we have reported at the end of the sprint. During the sprint review (retrospective) we are discussing about our weak points, wrong turns during the past sprint and define new ways to overcome them within next sprint. And also we discuss about our good practices and ways which we can improve them on coming sprints.

I have used terms like test lead, developer and tester for explanation the process. But we have only three roles within scrum frame work, such as product owner, scrum master and team members.

This is my idea about how we do scrum.

A simple IDEA about Cloud Computing and SaaS

 

SaaS can be defined as IT related services a client can get through internet by paying monthly subscription for the solution they are using. In SaaS, client needs not to pay the whole amount at once for the solution which they get. And client is not the owner of the application, because of that they need not worry about application maintenance and the software, hardware upgrades.

Cloud computing is a service that you get through internet for your IT needs by paying only as use it. It’s like an upgraded version of software as a service (SaaS).

In general cloud computing and SaaS are integration of following key points

1. Virtualization.
2. Utilize Computing.
3. Pay for Service.

Virtualization.

In Virtualization application components are independent from the infrastructure. That means clients need not to use their own application severs, DB server or middleware components (Integration components) in the same infrastructure. Basically application severs DB server or middleware components can run pretty much from any on globe with out dependent from each other. Actually it runs in the cloud, a cloud that charges only as you use it.

Utility Computing

If we think from client user side, client need not spent money for their own mainframes, server computers, data security and for the utility software license. Also they need not to spent money for the Software maintenance staff. They only need to pay their monthly subscription for the software service providers.

Pay for Service

Client users only need to pay for service they get from their software service providers.They need not to pay for the whole solution and they need not to pay whole amount at once.

For further understanding if get a common example to understand these concepts.

- Buying Licensed Software is like that buys your own car, by pay the whole amount of money whether you used it or not.

- Using SaaS is like leasing a car. Leasing company really owns the car and Client only needs to pay monthly fixed installments.

- Using cloud computing is like going some where from TAXI. Client only want to pay for distance they go. So it’s very economical for the clients because they only pay for the distance they travel. By the way it’s also economical for the TAXI owners because there may be many clients using same TAXI when they want.

This is my simple IDEAs that I have regarding on Cloud Computing and SaaS.

QA with Zero BUGS is possible?

I think as testers we should try to deliver a project with at least no bugs in live-environment, in other words there should not be customer identified bugs. As I believe there are some facts which help to minimize customer identified bug count. In most of the customer testing periods they are testing the scenarios which can happen in live-environment (There can be positive or negative test scenarios). So if we want to hunt down the bugs before they do, we should be customer-minded.
In my point of view there are three main reasons which help us for this kind of testing.
1. Expertise the Domain knowledge.
2. Some knowledge in Combination & Arrangements.
3. Some knowledge in Probability.



Expertise the domain knowledge.

Tester should have a deep knowledge of the domain because they are the people who keep the solution as customer expected. (How much a tester expertise the domain knowledge he can get that much of success in testing). Most of all, tester must know how the business happen in practically, then the tester can identify the scenarios which can happen in live-environment.


Combination & Arrangements.

If tester knows the business logic well then he can list down all the possible combinations with in very short time period. Because of understanding about Combination & Arrangements, tester can list down most of the test scenarios and tester can prevent from testing the same scenario twice. This will be very efficient for tight time-lined projects.


Probability.

After list down the possible testing combinations, tester can give a probability value to every testing scenario by considering the probability that gets in live-environment. And then tester can prioritize the test scenarios according to probability value. For an example suppose that there are two paths of submitting an order. According to business happened in real time, 7 users are following path1 (P1=0.7), 3 users are following path2 (P2=0.3). And assume that tester have 100minuts to test those two paths. By considering probability values I suggest it’s more effective if tester can give 70mins for testing path1 and 30mins for testing path2.


And also if test team can do parallel testing with above method I hope we can deliver projects with no customer identified bugs in live-environment.

New Trends in SQA - Continuous Integration

Continuous Integration (CI) is a modern trend to improve the quality of software. In this software development practice every team member can integrates (merge changes with repository) their work frequently; usually each person integrates at least one time while the team member completes one task. Each integration is verified by an automated build (snap-shot) and automated testing to detect integration errors software defects as quickly as possible. This approach leads to reduced integration problems and allows a team to develop more stable software more quickly.

If I explain this more, after developer starts his work by taking a copy of the current integrated source onto my local development machine, take the working copy and do whatever need to do to complete the task. This will consist of both altering the production code, and also adding or changing automated tests. I mean as ‘automated tests’, mostly the unit testing which can use such as Xunit, JUnit, TestNG testing frameworks.

Once the developer done with the task then, he wants to makes snap-shot with recent changes. If the snap-shot build with out errors then developer should run the automated test. Only if it all builds and tests without errors then the overall build considered to be good. Once the developer has made the build of a properly synchronized working copy then he can finally commit my changes into the repository.

The whole point of Continuous Integration is to provide rapid feedback. A simple example of this is a two stage build. The first stage would do the compilation and run tests that are more localized unit tests with the database completely stubbed out. Such tests can run very fast, keeping within the ten minute guideline. However any bugs that involve larger scale interactions, particularly those involving the real database, won't be found. The second stage build runs a different suite of tests that do hit the real database and involve more end-to-end behavior.
And also if you test (mainly the second stage) in a different environment, every difference results in a risk that what happens under test won't happen in production. So testers have to test in a Clone of the Production Environment
On the whole I think the greatest and most wide ranging benefit of Continuous Integration (CI) is reduced risk. As a result projects with Continuous Integration tend to have fewer bugs, both in production and in process.

Continuous Integration - Diagram

What is QUnit

QUnit is the unit testrunner for the jQuery project. It's especially useful for regression testing. Having good unit test coverage makes safe refactoring. You can run the tests after each small refactoring step and always know what change broke something. This QUnit unit testrunner is very useful, because most of Testing tool are not competible woth Ajax and jQuery.

Test Maturity Model Integration

Test Maturity Model Integration (TMMi).

The software industry has much focused on improving their development processes. A guideline that has been widely used to improve the
development processes is the Capability Maturity Model. The Capability Maturity Model (CMM) and its’ successor
the Capability Maturity Model Integration (CMMI) are often regarded as the industry standard for software process
improvement. Then the testing community has created its complementary improvement models. This document
describes the Test Maturity Model Integration (TMMi). The TMMi is a detailed model for test process improvement
and is positioned as being complementary to the CMMI.There are five Maturity Levels of this TMMi.