Managing Mobile Coverage in an Agile World

Managing Mobile Coverage in an Agile World

Leveraging JIRA and Scrum

Moderator: Today, the presenters are Jay and Stanley. And they are our senior career managers here at Infostretch and QMetry. And they have been handling strategic accounts for us for a long time. Without further ado, I give it over to Stanley and Jay to start again. Thank you, guys. Stanley: Okay. So I’m going to go straight into the Scrum construction lifecycles, so let’s get started. So with the Scrum IT, you may have, but highly unlikely, you have functional specification and high-level design documents that you can use to write the test specification and test case design documents. More than likely, what you see in the Scrum methodology is a set of revolving requirements that will actually maintain in the product backlog. So the product backlogs are product requirements in the form of use of storage, so Epic product managers that are typically the ones that maintain the product backlogs. And usually, from our experience, this is, at this time, that the team should have to test the IT document at this time, too. What’s contained in the strategy document is what kind of tests will be automated, what are going to be manually tested, what your environment looks like, what are the devices that you’re going to support, etc. So these are kind of more strategic discussions. During the sprint pre-planning meeting, the highest priority requirements are pulled from the backlog. And that may be delivered in their sprint cycle. So basically, if your sprint cycle is between two to four weeks long, you pull out requirements from the backlog that you can deliver within this cycle. So during the sprint-timing meeting, that’s when you have your sprint team to go over the requirements. And it is at this time; you start to develop your task, your test requirements, and your test specifications. And then moving on to the next phase is the sprint cycle. This is when the execution begins. You have your daily stand up meetings to share your user stories and identify potential issues. Some teams may start to ask for test reports. And then, at the end of the sprint cycle, there’s a sprint review. And this is time for where you can demo your user stories. At this time, you may also have a release note being generated, a report of all of the tests that have been executed. Typically, a user story is complete when implementation and testing are done. So also, at this time, all of the tests should have been passed. So in the next few slides, I’m going to talk more about this in detail. So let’s move ahead. So let’s go through the pre-planning phase. In the sprint pre-planning meeting, you start to define user stories. And a typical user story – I’ll give you an example of a user story, as a user, I can activate my gift card. That in itself doesn’t give a whole lot of guidance in terms of what kind of test cases you use or test specification you need to develop. So a better example would be, as a user, I can activate my gift card from our Grade A desktop and mobile browsers. But this is really enough information as to how am I going to start my test specification? So the output of this pre-planning phase are a set of user stories that could be implemented in the sprint cycle. So next slide. So in the spring planning meeting, these are where you start defining test cases. When are the test cases going to be developed? For example, activate gift cards from the Internet Explorer versions 7 to 9, Firefox 10 to 13, and so on. And here, you start to develop what are those test cases? If you have both manual and automated test cases or just manual ones, the question you might have is where do you document these test cases? In some cases, the test cases are documented in the Scrum tools. And the substance criteria is actually documented a free test format. In some cases, test cases are documented in Sticky Notes. In some cases, a test management system is used. But where is the traceability back to the user story? So these are some of the questions you may have when you’re doing the sprint planning is really the question to ask is where do you store these test cases and where do you retrieve these test cases when you need them? Okay. Let’s move on to the next sprint cycle. Now, you’re in the sprint cycle. This is your executing. This is where the user stories are implemented and tested. As a QA role member, how do you generate the test report for your daily stand up meetings? These are questions you should be asking. How do you articulate, for example, that activation works on certain browsers but not others? Will you remember this with every user story in the sprint? Are you going to remember the status? How do you report on the status? So during the sprint cycle, you’ll probably be asked to run regression tests. As new pieces are being introduced, are there regression? So these regressions also include tests from your past sprints. So it’s not just about your current sprint. You may be four or five, six sprints into it already, and you’ll be asked to rerun all of those test cases, especially if you have a manual and automated requirement. Where do you get that list of test cases to execute? So these are some of the high level questions you’ll be asking. Next slide. So in the sprint exit, this is where the sprint cycle is done. All of the user stories are completed and tested. So typically, at this time, you’ll be requested to rerun all of the regression tests to make sure there are no regressions before you push the product out. The question you have is what are those test cases that need to be re-executed. If you documented in Sticky Notes, where do you go to get those test cases? If you documented in a Scrum tool, are you going to be able to retrieve those test cases? So that’s kind of really a high level problem standard. So in summary, what I’m going to do is pre-planning includes high-level design and test requirements. And in the sprint planning, where are the users’ stories and test requirements and test cases, where are they stored? In the sprint cycle, during the daily stand up, how do I report on the test execution? What is the status? What are the issues? What works? What doesn’t work, particularly in the platform related areas? Sprint exit, what are the regression tests? How do I generate test reports or the release notes? So these are kind of really high level questions. And I know there will be many more questions you can ask. The next step is seminar. Jay will present the Infostretch product. And we’re going to talk about how we can use QMetry and how it interfaces with JIRA. Next slide. So as Infostretch, QMetry solution with JIRA, so in JIRA, some people are using JIRA as a Scrum tool. So user story, product defects, customer defects, customer request for enhancements of JIRA as a requirement. What we can do is we take the user stories, the defects, and the request for enhancements and keep them as test requirements and feed that into our QMetry test management products. So eventually, all of these user story defects and requests for enhancements gets mapped into test requirements. Next slide. So during the sprint cycle, this is when you start to define the test cases and platform certification. So we envision that, while you’re in the sprint planning meeting, you’ll have a Scrum tool like JIRA managing your user stories, and you’ll have a test management to be able to describe entering your test cases for those user stories. The important thing here is that this takes ability back into the user stories. Next. During the sprint execution, QMetry can send test case status back into your JIRA so that you can actually see the test case progress. Next. There is also interface to rally. And that’s not the subject of this webinar, but the possibilities are there. Next. So now, I’m going to turn the table over to Jay. And he’s going to talk a little bit more about the QMetry. Jay: Thanks, Stanley. So as Stanley figured out or he brought out the problem statement as to how we drive down the best details throughout the – how do we drive down the stories, test cases? So what is the common solution? The common solution right now here at Infostretch that we have implemented is using a total test case management space called QMetry. So I’ll just talk about briefly as to how we use QMetry to implement our agile process and how do we track stories requirements from an integrated JIRA to manage our sprint. So this is nothing about a best of a total test case management suite, which is much flexible in terms of collaboration with the third party tools or integration and automation part of it. And it’s intelligent in terms of providing visibility through reports and have dashboard reporting systems, which are automatically created during the testing phase during the testing cycle. So the other thing is like it’s very easy in terms of solution. Like we can have a very easy solution deployment, which this particular tool has and on premise module. Then, the major important thing is integration with all third party tools. So basically, in our seminar where we are going to be using JIRA for integration, when we are going to put in the requirements, which are nothing but the story for your sprint. So from an integration point of view, we will see how easy it is to integrate those with the QMetry side. And it’s proactive. It’s like early bug detection with sophisticated background technology that helps to figure out what are the issues that we are going to encounter or what are the things that we need to take care of before. So moving on to the next one, what does QMetry do? It has the ability to add requirements. So these requirements, typically, can be imported from JIRA. Or it could be a new feature or issues that are going to be locked in. Or it also has an ability to maintain test cases as well as to create new test cases and import test cases. Secondly, it also has a feature to create the test, which where you can reuse test cases in different test scenarios. Use cases that may contain multiple issues that come through. Or it’s an easily maintainable test, which will help you for test case execution cycle. It also has the ability to add platforms, depending on how your sprint cycle is. So typically, the platforms will be like what kind of browsers you’re going to test your particular application or in case of which are the others that they are going to target for your testing purpose. Or in case of mobile, what kind of device you are going to do. So it has the capability to define the platforms on which you are going to execute your test cases. Then, your automated test results and reports. So basically, you can have the test results being generated automatically. You don’t have to add specifically about how do I create the reports. So as your test cycle progresses, or as your testing progresses, these reports are automatically generated where it’s going to give you an entire dashboard of your entire sprint. Then, it has an easy way to log new issues against the requirements and test cases. So with the integration with JIRA that we’re going to use, it has the ability to attract and pass on information back and forth so that it’s easy to track down the issues. As I said, it’s bilateral and bidirectional integration, so you can put in information, and you can review your status from JIRA as well as from QMetry. So how do we manage testing in sprint is we, typically, have the – like how do we collect the requirements is, basically, in JIRA. So either the bug that we have in our previous sprint and that they are the ones that is going to register your requirements or user story. Or an system that an organization is using to drive down customer support issues, they also contribute to your stories or to the requirements. You may have some certain instruments that will be a part of your story or your requirements. There could be new pictures, or, as I said, a backlog of any of the previous sprints that comes as part of your requirement. So what we typically do is here, there’s one . Okay, these are the requirements. As we plan the sprint, as Stanley mentioned, during the sprint planning, we decided to retell the stories of each of the requirements that are going to be part of your sprint. And then, we’ll take it down like depending on how large the stories are and how long the sprint cycle is going to be. We put all of these stories into stacks, which later on gets assigned to particular developers or the QA team members. So how do we do a JIRA. How do we exactly use it? So what we do is, as I said, like as a or as any of the business stakeholders, they come up with the requirement, which is then logged into JIRA, and these are the new enhancements and requirements that come. So when we define an issue, we have a description and . So specifically, what we do is, during logging the requirements, what we explicitly mention about is like in the description the steps that we are going to – what are the steps that contributes to the test case steps? Then we also have to mention, or rather we mention here, like we said, the affected . And what is the plan of sprint that we’re going to do specifically? So these are nothing but a smart screen that have been diverted in JIRA. So that helps us to track down in QMetry against which sprint we are testing against what sprint we are planning to release this cycle. So to be implemented, we do have that nomenclature to organize and define the way they want to develop the sprint as a cycle or build . But these are the reasons as to how they are going to map the sprints from JIRA to QMetry, which will help us in one on one mapping during a sprint. So the other point is like importing the fine tuned requirements from JIRA to QMetry. So the credit of the , which runs on a regular interval. So as the requirements have been updated, those requirements get pulled into QMetry once we establish this integration within JIRA and QMetry. So where these are already set up based on management, so it will populate the fields in QMetry, and it will define what spring is going to be. So one to one mapping of JIRA instead of going into QMetry requirements with it. So with QMetry and JIRA, what do we have is like, as I said, like the integration is nothing but that we have to mention in QMetry to start up the integration between JIRA and QMetry. So those particular 5.0 and 4. So we also have a , from QMetry and link existing issues to QMetry test cases. It is one part that you can link against to which test case the particular JIRA has been required. Also, we have a facility to map it down to the requirement. So like we can go down and say for which requirement a particular test case has been developed. And for that, what is the issue that has been tried again? So that part has a more linking ability. So is like you have been executing your test cases. And you encounter a bug or if the test case fails. So there is a facility to directly create the issue or a JIRA issue from QMetry itself, which will have it hosting back onto QMetry. This is all possible due to the integration and the API calls that we keep checking. We also create QMetry test cases from JIRA. So with this API that we have or the integration that we have, we can directly create test cases from JIRA, which would be part of your QMetry so that it’s easily accessible from either from QMetry or from JIRA. So as Stanley has explained to you that this sprint cycle could get shorter like in some organizations, it could be a one week cycle or a two week cycle. So everything to be , it is very difficult to drive down the test cases, drive down the automation test case, make sure it’s been tested against all of the platforms. And how do we maintain it all to QMetry? So basically, with the shorter cycle, the ability to convert directly your test cases, your requirements or stories into test cases, is definitely helpful in this kind of a shorter sprint cycle. So I’ll just quickly, in the next to slides, I will just give you a TCM, which is a test case management flow, and then I’ll quickly demonstrate as to what the integration is and how it works through QMetry. So in this test case below is what we do is test case management flow is we see this test case is directly from the requirement. But there is an ability to convert your requirements to test cases. We have just a kind of a design or one step approach where it directly can work as a requirement to your test case. Second is, if as the tester, you plan to have some other test cases, which definitely will be a part of it, so there is an ability to write test cases as well. Or one requirement is it may not be a one to one mapping of test case to requirement. But there are definitely – there will be definitely more than one test case for requirement. So we have that ability or the QMetry has that ability to map all of those things. What exactly is the test suite? It’s like we group all of these test cases into test suites or the scenarios. So for example, as Stanley said, with the sprint or the agile methodology, it’s like how we are going to maintain the integration suite. It’s going to grow and grow as per every sprint that is going. So every new functionality is going to contribute to your regression cycle. But if you have to execute this regression, for example, is how we’re going to manage it. So what we typically do is we clear that test suite. We can copy it over from one sprint to another. So that’s easy flexibility to copy our test case and your regression from one sprint to another, and then you can execute them as per your availability and the sprint cycle function. So we also maintain the organize the testing basically. So as I said, you just execute the test suite, and then we will see how do we maintain the test cases. The important feature is like the platform manager, the ability to create a platform. So the slide I just explained, like the ability to create the platform is one key feature in terms of how do we, during our sprint cycle, how are we going to manage our browser compatibility issues? Or as in this example, which I have taken as like gift card transaction that goes through the mobile devices. How do we guarantee that it has been tested across all? So what we have featured here is it helps you to create your platforms and then define your test suite and assign your test suite to those platforms so that way, it is easy to track down how these test cases perform against this particular platform. And all this will contribute and you will have a reporting facility to judge or see how did a particular test case perform on a particular platform or maybe iPhone device. What were the results of all the test cases? So all of those features will be incorporated and that helps this platform to create that one. So it particularly creates ones and you use it all the time in your different sprints. So we are on the last one like test results and reports, which, as I said, the test reports and the dashboards are automatically generated and updated. So integrated and manual and automated test cases, there is a facility to integrate the automation part as well where we have a QMetry agent, which could take any of your automated test cases. So we have a combination of your manual test cases and automation test cases. But in the reporting structure, you can definitely have a combination of how many of them went through the manual part, how many of them were the automated test cases. So you have a mixed bag where you can have an automatic reporting system. And all of this has been done in the background while your test cycle or your test sprint is being executed. So also, you can see for a particular sprint how many new defects can be generated or what was that original requirement? Can we close this requirement? It helps facilitate to track down your requirement as well as reporting structure. So I will quickly give you a walk through as to what we have done in terms of agile methodology at Infostretch. So I’ll give you a quick walk through of the application. So just bear with me for a minute. Okay. So I will quickly give you a walk through as to how we define those things, how we have used QMetry to add an agile Scrum tool for Infostretch. So as I said, one of the important features that we described is the ability to integrate with different tools. So in that case, we have done that for our JIRA. So typically, the setting goes like we have to integrate the platform that’s the JIRA. So we provide the credentials. Okay. So in the integration, we have the facility as to which system you want to integrate. So in that case, what we have done is we have integrated with JIRA. But since I’ve already done it, specifically, I’ll just go ahead and show you the process of how do we integrate. So it’s nothing but the API system that we have to specify where we are. Your JIRA . The moment we do this setting, there is an integration that has taken place from QMetry to JIRA. So the other part is basically what we have . Once this is done, we can also do that with the product. And so I guess which product we are going to use this integration, and we can specific what is the different tracking systems for the tools and what are the requirement tracker that they are going to use. So I can see here it’s like the JIRA is what we have integrated. And that will help us to import the requirements directly from JIRA. So this is the instance of JIRA wherein we have created all the requirements that are mapped out. If you have a look at one of the integrations, what we have done. One of the requirements of the story is basically we have described what is the requirement of somebody and the description as to what we are going to need. So if it’s management suite where we are going to import the requirement or the story basically. If we go to the import requirement log in, but before that, I would also like to show you that the integration that we did with QMetry, there is a result. You could see that what is defect tracking system and the requirement tracking system. Under the requirement tracker, this is where you’re going to import. This shows that the connectivity has been established. So in this page now, what exactly I’ve done is I have created a space to import the requirements from JIRA. So if you go to the requirements part, there is an ability to import requirements. So you could either import it through Excel or through import tracker. So in that case, we have done it through our import tracker where it is designed, which will help you step by step as to how you’re going to map your requirements or story fields to the fields in QMetry. So in QMetry, we also have the ability to define user defined fields, which will help you to actually map the fields statically that have been populated from JIRA to QMetry. So in this case, I just canceled it because I have already set up the sprint and imported this down here. I’m sorry, the requirements are here. So now, as you’ll see the requirements that were out in JIRA, the same have been imported back out here. And it also gives you for which screen it is applied to, so in this case, it is what’s the JIRA that you could . One is the JIRA number where you could identify that back into QMetry. Now, the important part out here is like now that we have got the requirement with the shortest sprint item, the best ability out here is to requirement . So it’s a one click, one step process wherein the requirements are directly converted to the test cases. You need to provide the necessary information like defining the priority, what kind of test this is, whether it’s a functional regression, automated, manual. So basically, you can define all of the major necessary information, and then just save it. So what it does is it creates a test case. So if you go down to the test case model, you will see that the test case, which is also . So this is the test case. Basically, it gets down into a test where you have not done two steps and all the information that has been provided. If you see, it has been linked back to the requirements, so from a point of view, it shows against which requirement this particular test case has been linked to. Similarly now, once the test case has been created, the next step is to execute that test case. So as demonstrative of what I’ve told you, there is a facility to create that suite. So basically, it’s nothing but a folder manual wherein you know you assign all of your test cases to find all the other data that has been created from your requirement. So again, here, also, you will see that the test cases are linked back to the test case that you have created out here, which is maybe a balance inquiry. In that case, it was a balance inquiry. So that is one part. If you go ahead and go with the execution part of this, before that, understand, there is an ability to define the platform. So this platform has been defined or has been created from the admin panel out here. You can set up and recharge the platforms that you will need for your for testing cycles. So these have already been created. This was just a quick walk through. But yeah, before you actually go with your test case execution, you will see there is an ability to assign your test case to the platform. So in this case, since we are doing it on mobile devices, I have created for three different mobile devices like Samsung, iPhone, Motorola. And I have applied the platform to the test cases. So that’s where it will be. We will know how the test case has performed against a particular platform. So if you go ahead and see, let’s go with the actual execution part of it. So for us, right now, we can just go with the manual test case. And come down here to a manual test case. So here, we have the ability to either build onto the set, and you can mark , or you can test it on the whole. You could . So in this case, let’s . But for this round, what I will do is maybe I’ll mark it as speed, and then we’ll see how we do. So let’s go ahead and mark it as speed. So , what I’ll do is I want to create a link to a JIRA. So now, we can see this particular requirement has been mapped to a test case, which is to a test suite. And now, I can get an association where I can link it to an existing issuing JIRA, or I could create a JIRA directly from QMetry. That’s the beauty of the integration part that we are doing. So another part is like the description, which will be like from the local point of view. Your description, it helps to give you a step by step walk through as to how it would refer to the issue. And as you do any of the tracking system, you could mention what is the priority. It all depends on how you want to put in the information. So provide the detailed information maybe like Windows, admin, and I’ll say create issue. This is what I do. So once the issue has been created, it will get automatically assigned back to your different tracker. That is the ID where it is created. Now, if you want, you can have a look at it, or you can directly go back to your JIRA where it has created the issue along with the. And then, also, another cool feature that QMetry has provided is, basically, you can also have a quick look at what was at that space . So let me go back here. It will give you all the entire details of, again, which test case. It gives you the of the test case. Or this is a quick one, which is validated by an inquiry from . What you do is, from this integration, you can also have a quick look at what exactly the test case was. So coming back to QMetry, so this is where you can update the test case status, close it. And you are done with your test case integration part. So the other major important part now from a reporting structure or from the management side is like we have this reporting facility. During your daily Scrum, you want to update your status as to where it was mentioned that from a nomenclature point of view, we have defined the build as – not the build, but the cycle as sprint and the build as Scrum. So there are various tests. . So let’s say first is the requirement by . So for the demo purposes, I had created four test requirements out of page. This requirement has failed because the test cases are facilitated with this requirement and failed somewhere. So the ability, you can drill down as to go ahead and see which are the requirements. Now, once you go, you can go to the requirement and see the ability of what was the exact requirement. And if you want, you can, again, track down to which test case that requirement was and against what it has failed. So from one dashboard, you could get the overall picture of your requirement of how the requirements are tracked down in the sprint. So the other report that you would like to look at will be the test case execution status as to how many test cases have been executed overall. How many of them fast? How many of them were not run? And how many of them were blocked? So as I said, the building of that platform spot is like you can have your test cases or the results of your test cases according to your platform that you have executed the test case on. So let’s say on iPhone, there were six test cases out of which six passed out of the test cases that were defined for this particular platform. And only one was not. So also, you can have it according to the test suite. Since we have that ability to according to the test suite, so we can mention, for activation, let’s see how many of them work. The total were three, out of this . So this gives you a quick snapshot of your entire sprint cycle defining how you have progressed right from requirement to the reporting structure. So this gives you the ability to make a good on your particular sprint as to do we really want to release the sprint, or what is our approach that we are going to take to improvise or go ahead with this . In case you have an expert, query writers who want some differentiated reports, so we also have . This particularly will give you the ability to create your own reports. So there are certain reports where you can have a detailed attach reports where in terms of data summary report or data report of your entire cycle. So this gives us the ability to track your entire sprint. So yeah, we are open for any questions or any suggestions, ideas. Thank you. Moderator: If you have any questions, please type into the chat panel. We will take five minutes to look get them answered. So if you have any questions, please type them in the chat panel. Thank you. There is one question, and it’s not about Scrum or agile. But it’s a question to both the . Jay: Yes, it does. So both the has the facility of integration. So it will behave in the same way as demonstrated out here. Moderator: Okay. One other questions, it says is QMetry compatible in 5.0? Jay: Yes. In the slide, I mentioned that it is compatible with the version 4 and 5. Moderator: Okay. Thank you.

Leveraging JIRA and Scrum

Moderator: Today, the presenters are Jay and Stanley. And they are our senior career managers here at Infostretch and QMetry. And they have been handling strategic accounts for us for a long time. Without further ado, I give it over to Stanley and Jay to start again. Thank you, guys. Stanley: Okay. So I’m going to go straight into the Scrum construction lifecycles, so let’s get started. So with the Scrum IT, you may have, but highly unlikely, you have functional specification and high-level design documents that you can use to write the test specification and test case design documents. More than likely, what you see in the Scrum methodology is a set of revolving requirements that will actually maintain in the product backlog. So the product backlogs are product requirements in the form of use of storage, so Epic product managers that are typically the ones that maintain the product backlogs. And usually, from our experience, this is, at this time, that the team should have to test the IT document at this time, too. What’s contained in the strategy document is what kind of tests will be automated, what are going to be manually tested, what your environment looks like, what are the devices that you’re going to support, etc. So these are kind of more strategic discussions. During the sprint pre-planning meeting, the highest priority requirements are pulled from the backlog. And that may be delivered in their sprint cycle. So basically, if your sprint cycle is between two to four weeks long, you pull out requirements from the backlog that you can deliver within this cycle. So during the sprint-timing meeting, that’s when you have your sprint team to go over the requirements. And it is at this time; you start to develop your task, your test requirements, and your test specifications. And then moving on to the next phase is the sprint cycle. This is when the execution begins. You have your daily stand up meetings to share your user stories and identify potential issues. Some teams may start to ask for test reports. And then, at the end of the sprint cycle, there’s a sprint review. And this is time for where you can demo your user stories. At this time, you may also have a release note being generated, a report of all of the tests that have been executed. Typically, a user story is complete when implementation and testing are done. So also, at this time, all of the tests should have been passed. So in the next few slides, I’m going to talk more about this in detail. So let’s move ahead. So let’s go through the pre-planning phase. In the sprint pre-planning meeting, you start to define user stories. And a typical user story – I’ll give you an example of a user story, as a user, I can activate my gift card. That in itself doesn’t give a whole lot of guidance in terms of what kind of test cases you use or test specification you need to develop. So a better example would be, as a user, I can activate my gift card from our Grade A desktop and mobile browsers. But this is really enough information as to how am I going to start my test specification? So the output of this pre-planning phase are a set of user stories that could be implemented in the sprint cycle. So next slide. So in the spring planning meeting, these are where you start defining test cases. When are the test cases going to be developed? For example, activate gift cards from the Internet Explorer versions 7 to 9, Firefox 10 to 13, and so on. And here, you start to develop what are those test cases? If you have both manual and automated test cases or just manual ones, the question you might have is where do you document these test cases? In some cases, the test cases are documented in the Scrum tools. And the substance criteria is actually documented a free test format. In some cases, test cases are documented in Sticky Notes. In some cases, a test management system is used. But where is the traceability back to the user story? So these are some of the questions you may have when you’re doing the sprint planning is really the question to ask is where do you store these test cases and where do you retrieve these test cases when you need them? Okay. Let’s move on to the next sprint cycle. Now, you’re in the sprint cycle. This is your executing. This is where the user stories are implemented and tested. As a QA role member, how do you generate the test report for your daily stand up meetings? These are questions you should be asking. How do you articulate, for example, that activation works on certain browsers but not others? Will you remember this with every user story in the sprint? Are you going to remember the status? How do you report on the status? So during the sprint cycle, you’ll probably be asked to run regression tests. As new pieces are being introduced, are there regression? So these regressions also include tests from your past sprints. So it’s not just about your current sprint. You may be four or five, six sprints into it already, and you’ll be asked to rerun all of those test cases, especially if you have a manual and automated requirement. Where do you get that list of test cases to execute? So these are some of the high level questions you’ll be asking. Next slide. So in the sprint exit, this is where the sprint cycle is done. All of the user stories are completed and tested. So typically, at this time, you’ll be requested to rerun all of the regression tests to make sure there are no regressions before you push the product out. The question you have is what are those test cases that need to be re-executed. If you documented in Sticky Notes, where do you go to get those test cases? If you documented in a Scrum tool, are you going to be able to retrieve those test cases? So that’s kind of really a high level problem standard. So in summary, what I’m going to do is pre-planning includes high-level design and test requirements. And in the sprint planning, where are the users’ stories and test requirements and test cases, where are they stored? In the sprint cycle, during the daily stand up, how do I report on the test execution? What is the status? What are the issues? What works? What doesn’t work, particularly in the platform related areas? Sprint exit, what are the regression tests? How do I generate test reports or the release notes? So these are kind of really high level questions. And I know there will be many more questions you can ask. The next step is seminar. Jay will present the Infostretch product. And we’re going to talk about how we can use QMetry and how it interfaces with JIRA. Next slide. So as Infostretch, QMetry solution with JIRA, so in JIRA, some people are using JIRA as a Scrum tool. So user story, product defects, customer defects, customer request for enhancements of JIRA as a requirement. What we can do is we take the user stories, the defects, and the request for enhancements and keep them as test requirements and feed that into our QMetry test management products. So eventually, all of these user story defects and requests for enhancements gets mapped into test requirements. Next slide. So during the sprint cycle, this is when you start to define the test cases and platform certification. So we envision that, while you’re in the sprint planning meeting, you’ll have a Scrum tool like JIRA managing your user stories, and you’ll have a test management to be able to describe entering your test cases for those user stories. The important thing here is that this takes ability back into the user stories. Next. During the sprint execution, QMetry can send test case status back into your JIRA so that you can actually see the test case progress. Next. There is also interface to rally. And that’s not the subject of this webinar, but the possibilities are there. Next. So now, I’m going to turn the table over to Jay. And he’s going to talk a little bit more about the QMetry. Jay: Thanks, Stanley. So as Stanley figured out or he brought out the problem statement as to how we drive down the best details throughout the – how do we drive down the stories, test cases? So what is the common solution? The common solution right now here at Infostretch that we have implemented is using a total test case management space called QMetry. So I’ll just talk about briefly as to how we use QMetry to implement our agile process and how do we track stories requirements from an integrated JIRA to manage our sprint. So this is nothing about a best of a total test case management suite, which is much flexible in terms of collaboration with the third party tools or integration and automation part of it. And it’s intelligent in terms of providing visibility through reports and have dashboard reporting systems, which are automatically created during the testing phase during the testing cycle. So the other thing is like it’s very easy in terms of solution. Like we can have a very easy solution deployment, which this particular tool has and on premise module. Then, the major important thing is integration with all third party tools. So basically, in our seminar where we are going to be using JIRA for integration, when we are going to put in the requirements, which are nothing but the story for your sprint. So from an integration point of view, we will see how easy it is to integrate those with the QMetry side. And it’s proactive. It’s like early bug detection with sophisticated background technology that helps to figure out what are the issues that we are going to encounter or what are the things that we need to take care of before. So moving on to the next one, what does QMetry do? It has the ability to add requirements. So these requirements, typically, can be imported from JIRA. Or it could be a new feature or issues that are going to be locked in. Or it also has an ability to maintain test cases as well as to create new test cases and import test cases. Secondly, it also has a feature to create the test, which where you can reuse test cases in different test scenarios. Use cases that may contain multiple issues that come through. Or it’s an easily maintainable test, which will help you for test case execution cycle. It also has the ability to add platforms, depending on how your sprint cycle is. So typically, the platforms will be like what kind of browsers you’re going to test your particular application or in case of which are the others that they are going to target for your testing purpose. Or in case of mobile, what kind of device you are going to do. So it has the capability to define the platforms on which you are going to execute your test cases. Then, your automated test results and reports. So basically, you can have the test results being generated automatically. You don’t have to add specifically about how do I create the reports. So as your test cycle progresses, or as your testing progresses, these reports are automatically generated where it’s going to give you an entire dashboard of your entire sprint. Then, it has an easy way to log new issues against the requirements and test cases. So with the integration with JIRA that we’re going to use, it has the ability to attract and pass on information back and forth so that it’s easy to track down the issues. As I said, it’s bilateral and bidirectional integration, so you can put in information, and you can review your status from JIRA as well as from QMetry. So how do we manage testing in sprint is we, typically, have the – like how do we collect the requirements is, basically, in JIRA. So either the bug that we have in our previous sprint and that they are the ones that is going to register your requirements or user story. Or an system that an organization is using to drive down customer support issues, they also contribute to your stories or to the requirements. You may have some certain instruments that will be a part of your story or your requirements. There could be new pictures, or, as I said, a backlog of any of the previous sprints that comes as part of your requirement. So what we typically do is here, there’s one . Okay, these are the requirements. As we plan the sprint, as Stanley mentioned, during the sprint planning, we decided to retell the stories of each of the requirements that are going to be part of your sprint. And then, we’ll take it down like depending on how large the stories are and how long the sprint cycle is going to be. We put all of these stories into stacks, which later on gets assigned to particular developers or the QA team members. So how do we do a JIRA. How do we exactly use it? So what we do is, as I said, like as a or as any of the business stakeholders, they come up with the requirement, which is then logged into JIRA, and these are the new enhancements and requirements that come. So when we define an issue, we have a description and . So specifically, what we do is, during logging the requirements, what we explicitly mention about is like in the description the steps that we are going to – what are the steps that contributes to the test case steps? Then we also have to mention, or rather we mention here, like we said, the affected . And what is the plan of sprint that we’re going to do specifically? So these are nothing but a smart screen that have been diverted in JIRA. So that helps us to track down in QMetry against which sprint we are testing against what sprint we are planning to release this cycle. So to be implemented, we do have that nomenclature to organize and define the way they want to develop the sprint as a cycle or build . But these are the reasons as to how they are going to map the sprints from JIRA to QMetry, which will help us in one on one mapping during a sprint. So the other point is like importing the fine tuned requirements from JIRA to QMetry. So the credit of the , which runs on a regular interval. So as the requirements have been updated, those requirements get pulled into QMetry once we establish this integration within JIRA and QMetry. So where these are already set up based on management, so it will populate the fields in QMetry, and it will define what spring is going to be. So one to one mapping of JIRA instead of going into QMetry requirements with it. So with QMetry and JIRA, what do we have is like, as I said, like the integration is nothing but that we have to mention in QMetry to start up the integration between JIRA and QMetry. So those particular 5.0 and 4. So we also have a , from QMetry and link existing issues to QMetry test cases. It is one part that you can link against to which test case the particular JIRA has been required. Also, we have a facility to map it down to the requirement. So like we can go down and say for which requirement a particular test case has been developed. And for that, what is the issue that has been tried again? So that part has a more linking ability. So is like you have been executing your test cases. And you encounter a bug or if the test case fails. So there is a facility to directly create the issue or a JIRA issue from QMetry itself, which will have it hosting back onto QMetry. This is all possible due to the integration and the API calls that we keep checking. We also create QMetry test cases from JIRA. So with this API that we have or the integration that we have, we can directly create test cases from JIRA, which would be part of your QMetry so that it’s easily accessible from either from QMetry or from JIRA. So as Stanley has explained to you that this sprint cycle could get shorter like in some organizations, it could be a one week cycle or a two week cycle. So everything to be , it is very difficult to drive down the test cases, drive down the automation test case, make sure it’s been tested against all of the platforms. And how do we maintain it all to QMetry? So basically, with the shorter cycle, the ability to convert directly your test cases, your requirements or stories into test cases, is definitely helpful in this kind of a shorter sprint cycle. So I’ll just quickly, in the next to slides, I will just give you a TCM, which is a test case management flow, and then I’ll quickly demonstrate as to what the integration is and how it works through QMetry. So in this test case below is what we do is test case management flow is we see this test case is directly from the requirement. But there is an ability to convert your requirements to test cases. We have just a kind of a design or one step approach where it directly can work as a requirement to your test case. Second is, if as the tester, you plan to have some other test cases, which definitely will be a part of it, so there is an ability to write test cases as well. Or one requirement is it may not be a one to one mapping of test case to requirement. But there are definitely – there will be definitely more than one test case for requirement. So we have that ability or the QMetry has that ability to map all of those things. What exactly is the test suite? It’s like we group all of these test cases into test suites or the scenarios. So for example, as Stanley said, with the sprint or the agile methodology, it’s like how we are going to maintain the integration suite. It’s going to grow and grow as per every sprint that is going. So every new functionality is going to contribute to your regression cycle. But if you have to execute this regression, for example, is how we’re going to manage it. So what we typically do is we clear that test suite. We can copy it over from one sprint to another. So that’s easy flexibility to copy our test case and your regression from one sprint to another, and then you can execute them as per your availability and the sprint cycle function. So we also maintain the organize the testing basically. So as I said, you just execute the test suite, and then we will see how do we maintain the test cases. The important feature is like the platform manager, the ability to create a platform. So the slide I just explained, like the ability to create the platform is one key feature in terms of how do we, during our sprint cycle, how are we going to manage our browser compatibility issues? Or as in this example, which I have taken as like gift card transaction that goes through the mobile devices. How do we guarantee that it has been tested across all? So what we have featured here is it helps you to create your platforms and then define your test suite and assign your test suite to those platforms so that way, it is easy to track down how these test cases perform against this particular platform. And all this will contribute and you will have a reporting facility to judge or see how did a particular test case perform on a particular platform or maybe iPhone device. What were the results of all the test cases? So all of those features will be incorporated and that helps this platform to create that one. So it particularly creates ones and you use it all the time in your different sprints. So we are on the last one like test results and reports, which, as I said, the test reports and the dashboards are automatically generated and updated. So integrated and manual and automated test cases, there is a facility to integrate the automation part as well where we have a QMetry agent, which could take any of your automated test cases. So we have a combination of your manual test cases and automation test cases. But in the reporting structure, you can definitely have a combination of how many of them went through the manual part, how many of them were the automated test cases. So you have a mixed bag where you can have an automatic reporting system. And all of this has been done in the background while your test cycle or your test sprint is being executed. So also, you can see for a particular sprint how many new defects can be generated or what was that original requirement? Can we close this requirement? It helps facilitate to track down your requirement as well as reporting structure. So I will quickly give you a walk through as to what we have done in terms of agile methodology at Infostretch. So I’ll give you a quick walk through of the application. So just bear with me for a minute. Okay. So I will quickly give you a walk through as to how we define those things, how we have used QMetry to add an agile Scrum tool for Infostretch. So as I said, one of the important features that we described is the ability to integrate with different tools. So in that case, we have done that for our JIRA. So typically, the setting goes like we have to integrate the platform that’s the JIRA. So we provide the credentials. Okay. So in the integration, we have the facility as to which system you want to integrate. So in that case, what we have done is we have integrated with JIRA. But since I’ve already done it, specifically, I’ll just go ahead and show you the process of how do we integrate. So it’s nothing but the API system that we have to specify where we are. Your JIRA . The moment we do this setting, there is an integration that has taken place from QMetry to JIRA. So the other part is basically what we have . Once this is done, we can also do that with the product. And so I guess which product we are going to use this integration, and we can specific what is the different tracking systems for the tools and what are the requirement tracker that they are going to use. So I can see here it’s like the JIRA is what we have integrated. And that will help us to import the requirements directly from JIRA. So this is the instance of JIRA wherein we have created all the requirements that are mapped out. If you have a look at one of the integrations, what we have done. One of the requirements of the story is basically we have described what is the requirement of somebody and the description as to what we are going to need. So if it’s management suite where we are going to import the requirement or the story basically. If we go to the import requirement log in, but before that, I would also like to show you that the integration that we did with QMetry, there is a result. You could see that what is defect tracking system and the requirement tracking system. Under the requirement tracker, this is where you’re going to import. This shows that the connectivity has been established. So in this page now, what exactly I’ve done is I have created a space to import the requirements from JIRA. So if you go to the requirements part, there is an ability to import requirements. So you could either import it through Excel or through import tracker. So in that case, we have done it through our import tracker where it is designed, which will help you step by step as to how you’re going to map your requirements or story fields to the fields in QMetry. So in QMetry, we also have the ability to define user defined fields, which will help you to actually map the fields statically that have been populated from JIRA to QMetry. So in this case, I just canceled it because I have already set up the sprint and imported this down here. I’m sorry, the requirements are here. So now, as you’ll see the requirements that were out in JIRA, the same have been imported back out here. And it also gives you for which screen it is applied to, so in this case, it is what’s the JIRA that you could . One is the JIRA number where you could identify that back into QMetry. Now, the important part out here is like now that we have got the requirement with the shortest sprint item, the best ability out here is to requirement . So it’s a one click, one step process wherein the requirements are directly converted to the test cases. You need to provide the necessary information like defining the priority, what kind of test this is, whether it’s a functional regression, automated, manual. So basically, you can define all of the major necessary information, and then just save it. So what it does is it creates a test case. So if you go down to the test case model, you will see that the test case, which is also . So this is the test case. Basically, it gets down into a test where you have not done two steps and all the information that has been provided. If you see, it has been linked back to the requirements, so from a point of view, it shows against which requirement this particular test case has been linked to. Similarly now, once the test case has been created, the next step is to execute that test case. So as demonstrative of what I’ve told you, there is a facility to create that suite. So basically, it’s nothing but a folder manual wherein you know you assign all of your test cases to find all the other data that has been created from your requirement. So again, here, also, you will see that the test cases are linked back to the test case that you have created out here, which is maybe a balance inquiry. In that case, it was a balance inquiry. So that is one part. If you go ahead and go with the execution part of this, before that, understand, there is an ability to define the platform. So this platform has been defined or has been created from the admin panel out here. You can set up and recharge the platforms that you will need for your for testing cycles. So these have already been created. This was just a quick walk through. But yeah, before you actually go with your test case execution, you will see there is an ability to assign your test case to the platform. So in this case, since we are doing it on mobile devices, I have created for three different mobile devices like Samsung, iPhone, Motorola. And I have applied the platform to the test cases. So that’s where it will be. We will know how the test case has performed against a particular platform. So if you go ahead and see, let’s go with the actual execution part of it. So for us, right now, we can just go with the manual test case. And come down here to a manual test case. So here, we have the ability to either build onto the set, and you can mark , or you can test it on the whole. You could . So in this case, let’s . But for this round, what I will do is maybe I’ll mark it as speed, and then we’ll see how we do. So let’s go ahead and mark it as speed. So , what I’ll do is I want to create a link to a JIRA. So now, we can see this particular requirement has been mapped to a test case, which is to a test suite. And now, I can get an association where I can link it to an existing issuing JIRA, or I could create a JIRA directly from QMetry. That’s the beauty of the integration part that we are doing. So another part is like the description, which will be like from the local point of view. Your description, it helps to give you a step by step walk through as to how it would refer to the issue. And as you do any of the tracking system, you could mention what is the priority. It all depends on how you want to put in the information. So provide the detailed information maybe like Windows, admin, and I’ll say create issue. This is what I do. So once the issue has been created, it will get automatically assigned back to your different tracker. That is the ID where it is created. Now, if you want, you can have a look at it, or you can directly go back to your JIRA where it has created the issue along with the. And then, also, another cool feature that QMetry has provided is, basically, you can also have a quick look at what was at that space . So let me go back here. It will give you all the entire details of, again, which test case. It gives you the of the test case. Or this is a quick one, which is validated by an inquiry from . What you do is, from this integration, you can also have a quick look at what exactly the test case was. So coming back to QMetry, so this is where you can update the test case status, close it. And you are done with your test case integration part. So the other major important part now from a reporting structure or from the management side is like we have this reporting facility. During your daily Scrum, you want to update your status as to where it was mentioned that from a nomenclature point of view, we have defined the build as – not the build, but the cycle as sprint and the build as Scrum. So there are various tests. . So let’s say first is the requirement by . So for the demo purposes, I had created four test requirements out of page. This requirement has failed because the test cases are facilitated with this requirement and failed somewhere. So the ability, you can drill down as to go ahead and see which are the requirements. Now, once you go, you can go to the requirement and see the ability of what was the exact requirement. And if you want, you can, again, track down to which test case that requirement was and against what it has failed. So from one dashboard, you could get the overall picture of your requirement of how the requirements are tracked down in the sprint. So the other report that you would like to look at will be the test case execution status as to how many test cases have been executed overall. How many of them fast? How many of them were not run? And how many of them were blocked? So as I said, the building of that platform spot is like you can have your test cases or the results of your test cases according to your platform that you have executed the test case on. So let’s say on iPhone, there were six test cases out of which six passed out of the test cases that were defined for this particular platform. And only one was not. So also, you can have it according to the test suite. Since we have that ability to according to the test suite, so we can mention, for activation, let’s see how many of them work. The total were three, out of this . So this gives you a quick snapshot of your entire sprint cycle defining how you have progressed right from requirement to the reporting structure. So this gives you the ability to make a good on your particular sprint as to do we really want to release the sprint, or what is our approach that we are going to take to improvise or go ahead with this . In case you have an expert, query writers who want some differentiated reports, so we also have . This particularly will give you the ability to create your own reports. So there are certain reports where you can have a detailed attach reports where in terms of data summary report or data report of your entire cycle. So this gives us the ability to track your entire sprint. So yeah, we are open for any questions or any suggestions, ideas. Thank you. Moderator: If you have any questions, please type into the chat panel. We will take five minutes to look get them answered. So if you have any questions, please type them in the chat panel. Thank you. There is one question, and it’s not about Scrum or agile. But it’s a question to both the . Jay: Yes, it does. So both the has the facility of integration. So it will behave in the same way as demonstrated out here. Moderator: Okay. One other questions, it says is QMetry compatible in 5.0? Jay: Yes. In the slide, I mentioned that it is compatible with the version 4 and 5. Moderator: Okay. Thank you.