Writing test cases in a scrum project

Hi,

You can still use test case steps. But I advice to think about the real customer perspective. Maybe you can use INVEST model. Second point is automation for test cases. Also please share your test cases with whole team, because if you are not in the development team maybe all business stakeholders might have misunderstanding.

Thank you Cihan for your reply. What do you mean by "think about the real customer perspective" ? 

The relationship that you describe is confusing to me.

What type of application is this? Is it entirely custom development, is it an off-the-shelf product with some customizations or some amount of custom development, or is it a wholly off-the-shelf product that you simply buy and use?

You say that the organization developing the mobile app provides you with the user stories. However, they should be eliciting the user stories from you. As the organization that wants to buy and use the mobile app, you understand what your needs and desires are. As they are eliciting and capturing your needs, the development of acceptance testing can be a collaborative effort. However, as the organization that is buying and using the app, you should understand what you need to do to prove that the app is useful to you in your particular context.

The method of developing and using test cases effectively depends on the relationship between you and the application developer. Depending on the relationship, different options may make more sense.

As you described it, you are the stakeholder.  The Product Owner should be working with you to discover the need you have.  Those needs would then be captured in Product Backlog Items which by your description are User Stories. The user story should identify what your need is and how the Development Team will know they have satisfied those needs.  So you should be working with the Product Owner to capture all of that information BEFORE the Development Team starts working.  How to capture that information in a way that is best for the people building your product is a topic that you should be having with those individuals.  You and the Scrum Team need to be in agreement and have the same understanding on how to communicate. 

@ Thomas : thanks for the reply. It is an mobile application and custom development. The Product Owner writes the user stories based from our requirements/needs and we have full access to those user stories on jira. Before delivering a sprint to us, the company developing the mobile app do some tests too from their side but we the client (IT department) wants also do UAT so my mission is to write the test cases and execute the tests and then with the end-users

@Daniel:  thanks for the reply. That's exactly what we are doing but I am a bit confused on how to writes the tests cases, should i write them using the user stories (short and simple) or detailed with steps 

From what I can see, this should probably live outside of the Scrum process.

The developing organization can use any method that they want to build the software. Assuming that they are using Scrum, they should have potentially releasable Increments at least once per Sprint. As stakeholders, you should be invited to participate in the Sprint Review. The Product Owner is responsible for making the final decision on if the increment should be released or not.

What it means to "release" the Increment is not defined by Scrum. Although some organizations use it as "release to production", it could also mean "release to UAT" which could gate a final deployment to the production environment or app store. Once the development organization releases into the point of performing UAT, they are asserting that what they have is likely to pass your UAT.

You can write your test cases however you want. Ideally, they are based on the same information shared with the Product Owner and development team in the developing organization. They should also be based on how you know you will be using the system. This lets you perform a final check before accepting the software. You can send the UAT feedback to the developing organization through the Product Owner.

I don't see any reason to couple the way that you write your test cases to the way the developing organization is doing their work. You should do it in a way that makes sense to balance the needs of the end-users as well as making it easy to communicate issues found with tests to the developing organization.

@Thomas Owens said what I was going to say but he did a better job. 

I will add just one thing.  My background is Quality Assurance.  In fact, my current title is Senior Manager Quality Assurance (couldn't find a job as Scrum Master/Agile Coach so I took what I could when my previous employer was acquired and large lay-off occurred.)  I say that to add some level of credibility to this.  There really isn't a reason that you have to write test cases.  As long as you are validating the satisfaction of the information that has been given to the Scrum Team, you can do it with exploratory testing.  Just use the product as you would expect it to be used in order to validate that the solution works.  In fact, you might find issues with the original requirements by using a product vs testing a product. That information can then be provided to the Scrum Team so that they can adapt the product (inspect, adapt loop at its finest).  

If you do decide to write test cases, how detailed you write them is entirely up to you.  What level of detail benefits you since you are the one that will be executing them?  Personally, I prefer to write high level statements such as "An user can print a report of all recent activity" because in most cases there are multiple paths that can be taken through the UI to achieve that result. That way I can test multiple paths without having to write multiple test cases with detailed steps. But that is my preference and yours may different. 

This is very insteresting. Below the process in my project: 

1/ Sprint dev by organization developing the mobile app

2/ Tests are done by the organization developing the mobile app before delivering the it to the client

3/ The Organization developing the mobile app is delivering the app to the client to UAT

4/ I (the client) am in charge of writing the tests cases + UAT 

5/ The end users will also do UAT but with my help 

From I understand, there is no need to write tests cases (I could do exploratory testing) or no need to detailed tests cases but I am also in charge of designing the Test data for my tests, and for that, I have to prepare them before testing. So I am a bit confused ... 

I don't think that anyone can tell you what, if any, test cases you need to write or how detailed they need to be. Your process of performing acceptance testing is separate from the process that is used to develop the software.

Consider that you have a set of needs or requirements that you are expecting this to be fulfilled. If the developing organization is using Scrum, you are most likely interacting with the Product Owner to express those needs. The methodologies used by the developing organization has no impact on your objectives or methods to achieve them. Your objective is to validate that the output of the developing organization meets your intended use of the thing they are making.

You do not need anything other than an understanding of your needs and requirements in order to build an appropriate test methodology and document your test cases to a sufficient level of detail. You don't need to know anything about Product Backlog items, user stories, Sprints, or any testing that the developing organization does.

Remember that everything any of us have said is just our opinions.  You should form your own based on the organizational demands that you have and adapt your workflow as you discover more information.  But you have to start doing something in order to determine if it is effective.  

Good luck.  

For the acceptance tests, I have to write the tests cases for our business teams => so my question is : how should i write them ? should i use the user stories as tests cases or should i write them as in V cycle project (test cases with steps etc).

...

Below the process in my project: 

1/ Sprint dev by organization developing the mobile app

2/ Tests are done by the organization developing the mobile app before delivering the it to the client

...

My advice is to think a bit more about when you test, the extent and type of coverage needed for work to be considered "Done" and of release quality, and how tests will be automated to support regression. A test-driven approach to development might be wise.