Monday, April 18, 2016

User Stories |Agile Practices

User Stories |Agile Practices

A user story is an alternative way to express a software requirement in a very readable and structured form (based on the client perspective), in addition, user stories are the main tool to create the communication between the clients that demand the requirement and the team that will do the implementation (Regardless the methodology you are using).

The basic format of a user story is:
As a <Role> I want <feature> so that <benefit>

Few more concepts that you should know about user stories
·         Stories are added to the project “backlog” and from there to the “Sprint Backlog".
·         User stories are written by the PO (Product owner) based on the client/Business requirements.
·         Each story provides an alternative vision for managing the requirements of the software.

User stories – The Responsibilities 

Product owner
Scrum team
Who can Write stories?

Write based on client/business requirements
Not Relevant
Who is the Owner of the story?

The PO is the owner of the story prior to the commitment of the scrum team
Take the ownership during the sprint commitments
Who should Maintain the story?

The PO when there is a change during the project
The scrum team during the implementation process
Who should Prioritize the story?

The PO will do it when he need to prioritize the most valuable stories (Most valuable stories are developed first).
Not relevant
Who Will Execute the story?

Not relevant
The team is responsible to make the implementation

Why do we prefer to use "User Stories" in the agile methodology instead of a large SRS/STD doc that are used in the traditional methodologies?

Writing user stories is a simple task, you can describe the exact requirements without adding multiple long descriptions (Describes the exact requirements to follow).

User stories are a great way to increase the communication among the team members, and between the team and the product owner.

The team will review each story during the sprint "Planning" meeting, this will increase the discussion between the team members (Especially when the need to make the requirements analysis) so they will increase the knowledge prior to implementation.  

All in one
Each user story contains all the relevant information that the team members need to start the implementation (Acceptance criteria, Requirement specification and Done criteria).

User stories will allow the team to evaluate each story so they can determine the work effort prior to taking any commitment during a sprint.

Remember that each user story contains the work effort that the team needs prior to complete it, this effort is reflected in Hours that are reflected in the sprint "Burn-Down" chart that allow the PO/SM/scrum team members to determine the amount of work that completed/remained during a specific sprint.

Team Velocity
User stories are evaluated with "story points" these allow the scrum master/PO to determine the team 'velocity' thought the process, this info will determine the team capabilities and how much stories they can handle during a sprint.

How can you test the quality of your stories…?

The team discuss about the stories
A good user story will increase the discussion between the team members and reduce the need in detailed documentation, in other words, the team members will focus on how to accomplish the story and not to waste their time on writing every small detail.

Reduce the waste of Time
When you have a well written story, the team can start the implementation without wasting a precious time, in any case that you have a partial story or a story that haven’t written well, the team will have a delay in starting the story (or difficulties during the implementation), Examples:

·      Stories that have a Missing information (Acceptance criteria, Requirement specification and Done criteria) that the team cannot continue until you add it.
·       Stories that the team asks too many questions due to misleading information. 
·       Stories with very high uncertainty.

Everyone can understand them
It's simple, a good story will be the one that both the team and the customer can understand and Explain when asked. If one of them cannot due one of the two, the story is just not good enough.

A major concept in the scrum methodology is the using of "Story Points" to evaluate the work effort of a story, if the story is too big, cannot be tested or any other cause that is affecting the ability of the team to vote, this story should be re-written (Split to smaller stories, change the criteria…). This issue has become more important when such stories are arriving during the planning meeting where the team should make the actual voting cycles (poker game).


Additional concept in agile, is to create incremental software releases that will add the best value for the client, a good story will be the one that the team can implement and get the best value for the client. 

Thursday, April 7, 2016

Automation during the different phases of the SDLC process

At this article, I will try to explain why you must use an automation framework during the different phases of the SDLC process, I will do it by examining a list of eleven facts that will help you to get all the information that you need to get a future decisions

So why do we need to use automation during our testing effort...?

Fact no'1 - No one wants to repeat the same test twice
So you all familiar with the lovable testing method called "Regression" testing, well, without a solid automation, you will repeat your tests over and over again (Depends on the company software releases), which will eventually lead to a frustration among your testers.

Fact no'2 - Automation will save you time
I know that some of you will tell me that you need to put a Hugh effort to create any working automation so this fact is wrong, but let me tell you this, if you design a good and solid automation, that built with best practices right from the beginning, you will achieve :
  1. A working automation that is flexible to changes (can support new test cases, platforms or any other scenarios that you will need to add during the testing cycles).
  2. Reduce the effort of your manual tests with a minimum of 50-60%.
  3. Reusable code that you can use in other automation scenarios.
  4. Reduce the automation maintenance time.

Fact no'3 – Automation on all layers of the SDLC
Most people think that you use automation to run tests, well this is a very narrow vision, when you examine the different phases of the SDLC process, you will find out that you can use automation in almost every phase, just for example:
             1.Automated scripts to create your test environment.
2.Automated tests to examine a new build prior to releasing it to QA.
3.Automated tests on the UNIT and component level.
4.Automated tests that will examine a code modification.
5.Automated tests during the testing cycles.

Fact no'4– Automation as the gatekeeper
When ready, your automation will allow you to validate any code modification (both Edited/New) prior to release it to QA/customer (Classic for a small Service pack/Patch), this fact alone is priceless when you examine the amount of time that the engineering team will waste if this code modification will cause a major defect (Qa/Dev).

Fact no'5 – Automation can free your testers!
Think about it, after implementation, you can run your automated tests during the night hours, this will allow the testers to investigate the automation results in the morning and then they can focus on more complex tests (Especially on the “Nonfunctional” side of testing).

Fact no'6 – Automation can cover multiple test types
We can say today, that the new automation frameworks will allow the organization to cover many test types that were not supported in previous years, this will allow the organization to transfer the manual effort of performance, User interface and many other test types that until now where abandoned from the automation coverage.

Fact no'7 – Automated tests will improve the testing accuracy
Automated tests will do the same operation over and over again without any deviation from the scenario you defined (the same code will run with the exact algorithm until you change it). Now not like the automated tests, a manual tester will always have the chance to make mistakes when running is tests, therefore you cannot guarantee that the accuracy of the tests will be the same as you can achieve in the automated test process.

Fact no'8 – Automation can do things that you cannot achieve manually
It's simple, using a few commands, we can simulate testing scenarios that you simply cannot achieve with the manual testing process.

Fact no'9 – automation is fun!
Manual tests are great and I know that for some people, it's also the preferred testing method, but for me, developing automation tools/scripts are simply more fun and more effective than do the same operation over and over again.

Fact no'10 – Automation will allow you to narrow the costs
The main target of Automated tests is to replace the endless cycles of regression tests, after implementation, the automated tests will reduce the number of the manual testers that was required to run the same cycles prior to the automation coverage.

Fact no'11 – You cannot work Agile without automated testing
I will not review the Hugh important of automated tests in agile implementation, but I will say this, in agile we have a very short iteration (2-4 weeks), this iteration includes all the activities that involved in a software development process, therefore you cannot allow the waste of time of executing regression tests, this will lead to bottlenecks, waste of resources, and eventually will affect the team commitment.

My Presentations