Top Quality Assurance Tips for Test Case Planning Processes
Wonderment Apps is proud to present the Quality Assurance Roundtable, our series covering quality assurance processes within the development lifecycle. As a group of experienced quality assurance engineers, technical managers, and product developers, we would like to provide insight into the technical processes and best practices in a product buildout’s lifetime. In this episode of the Quality Assurance Roundtable series, we’re going to talk about quality assurance test cases and test case preparation, one of the most critical steps in the Quality Assurance process. We will provide some great insight into how the test case creation process looks like and also look at some of the best practices we follow at Wonderment Apps to ensure that we deliver the highest level of quality assurance service.
————-
Quality Assurance Roundtable Transcript
Top Quality Assurance Tips for Test Case Planning Processes
[00:00:05.710] – Ryan Williams
Hi everyone, it’s Ryan from Wonderment Apps. I’m excited to be here today to present our first QA Roundtable, Quality Assurance Roundtable. Today, we’re going to talk about a variety of subjects, specifically around QA, Quality Assurance, test cases and test case preparation. And hopefully, we provide some great insight for you on the process and how quality assurance works out Wonderment Apps and some best practices in general for going through that process for technology development. We’re excited to have our team here, our team leaders here to share with us today.
[00:00:45.070] – Ryan Williams
I’ve worked with them for quite a while, and they do an incredible job of really figuring out some of the spots that cause trouble before a project goes into production and causes trouble for its users. They’re really good at understanding what kind of user paths are challenging, how to actually test for them to make sure they’re working effectively and then and really cleanly report them back to the development team and in some cases, the product team. They have to. So I’m excited to talk more about the subject. But first, I want to introduce all of the team to you. So let’s start with Sergei. Sergei is Our director of QA, Quality Assurance. Tell us a little bit about yourself.
[00:01:30.560] – Sergei Shvab
Hi, everyone. Greetings from Belarus. It’s great to start our first great round here. So my name is Sergei, as Ryan mentioned, and I have eight-plus years of experience working in quality assurance. Around eight years ago, I started as a junior and growing during those years. Here in Wonderment Apps, I am head of the department and mostly working on establishing management processes, QA processes (Quality Assurance Processes) and I’m growing with this and I’m glad to grow with the team here in Wonderment.
[00:02:18.390] – Ryan Williams
Great. Thank you, Sergei. Yeah, thank you. Next up is Elena. Can you introduce yourself, Elena?
[00:02:27.660] – Elena Shpakovskaya
Hello, guys. My name is Elena Shpakovskaya. I’m a Quality Assurance Engineer. I have over 10 years of experience, tested mainly Web and mobile applications. And in the last years, I actively participate in establishing new and enhancement of existent, one of the processes on different projects.
[00:03:02.630] – Ryan Williams
Great. Thank you. Wonderful. And Anna can you introduce yourself?
[00:03:08.730] – Anna Melnik
Yes, sure. Hi, my name is Anna Melnik. I’m a quality assurance engineer for more than eight years before I came to Wonderment Apps. I have been working in a globally recognized software engineering company. I have experience in testing for desktop and web applications on a variety of client projects, such as educational software, applications for aircraft design, advertising tools. I came to Wonderment for more than one year ago and have a great working experience. Interesting audition and casting management software, advertising for a product. I met great people; excellent professionals and I am really excited to work there.
[00:04:11.200] – Ryan Williams
Great, thanks. Thank you. So when we think about quality assurance, we’re looking to try and find the best possible, most stable release that we can when we put something into production that requires it not only to be able to have good testing patterns to make sure that things work out effectively but also to understand what the usage in the business schools are of the product before they get into production so that we can try and foresee any problems that will happen. During that process, we really are up against quite a number of challenges. A lot of times we’re trying to understand how the product works and functions, especially before it’s launched, and that requires a lot of planning. So I was wondering, I thought we’d start by talking a little bit about what our planning process is like. And maybe each of you can tell me how do you do test case planning as you’re getting ready to QA, Quality Assurance a product. So Sergei maybe you can talk a little bit about what test case planning for you is like?
[00:05:25.290] – Sergei Shvab
Yes, sure Ryan. When Projects start, it is always very important to have a really good and detailed product requirement in order to start this case of creation and this case has a lot of benefits and especially profile cases like pretty big projects with a bunch of different users and user flows. And there is always a chance for a human mistake. And this case just helps us and great efforts to catch them and to get rid of a majority of defects. And the key purpose of this case is to ensure if different features of application or website are working as expected. And it also helps to ensure and validate if the software is free of bug and defect. And when we are starting to prepare and test cases, it’s always great to have some kind of common understanding of the whole project need for this. We are trying to create initially some kind of checklist, just high-level checklists, which shows all prospective, for example, just main user flows, main test data that will be used for test cases. And when this checklist is prepared, we can discuss this with this team, with the project team, identify any gifts, for example, in our understanding of this application, and then we can start creating detailed test cases. And this is another part of the process, of course, and when we have this checklist, it’s really great to start with product requirements and prepare and start to rise in these test cases and the requirements and prepare some kind of.
[00:08:10.500] – Ryan Williams
Well, I think we’re going to get to the requirements. I do have more questions on product requirements in just a minute. But I want to ask Elena really fast. How do you prepare? Are there any special preparations? I know we have to look at the product requirements but are there any special preparation steps that you take?
[00:08:33.490] – Elena Shpakovskaya
Yeah, you mean before reaching into requirements? Yeah?
[00:08:39.610] – Ryan Williams
Correct, yeah.
[00:08:41.350] – Elena Shpakovskaya
Before this, we have like a plan first here when we start to start thinking. But it’s not before. It’s like at the same time. But the plan is in parallel, but it’s a very important phase. I mean, this case development, because any work should be planned just and after that, it should be executed. So the more time we spend on planning, the better result we will get at the and the skills development is like a map for our future testing. When we have test cases, we have a logic and structure in our work, in our testing and structured approach will give us a possibility to control the process better to find more bugs and to have again a quality product in the end. And also during the skills development phase, we have time to prepare, strong meaningful tests that allow us to find the box, with high probability. So playing in the plan is very important.
[00:10:20.130] – Ryan Williams
Great so using that structure that you designed during that process. It gives you the best ability to prepare for all of the possible kinds of main situations that might have to be tested against. So thank you, Anna. How about you? How do you how do you prepare?
[00:10:44.910] – Anna Melnik
Could you please repeat the question?
[00:10:49.620] – Ryan Williams
How do you prepare for QA, Quality Assurance? What kind of steps?
[00:10:55.700] – Anna Melnik
Oh, yes, I agree with my colleagues that planning is the most important phase of development, and usually, I start from requirements analysis and understanding what business needs. After that, I start creating a checklist. It is like a high-level test plan, which will include the main functional models. And having these functional models helps us in the future to have a structure and like a logical map of our application. And having this structure, we can easily understand the full picture of the application and easily find the required area. So having this structure, I’m starting to define the priorities of all these functional models when I define priorities are usually user requirements. And by understanding main flows, which flows are the most important for a user having these priorities will also help me in the future to support that this case’s structure. So after that, I send my checklist to all team review to my manager, quality assurance manager, to the development team, to the business team. And after a review, I’m starting to see this creation process. So, yes, I agree with my colleagues, I think that planning is very important and it should be performed before this case is the creation and before we start this testing.
[00:13:51.190] – Ryan Williams
Great. Thank you. I appreciate it. Yeah, I agree. I think one thing I heard that came up a lot was using the requirements for the product specifications and the requirements of the user to be able to generate effective paths for testing to figure out the best way to actually tell whether the products are working or not. So it really comes out of those requirements. Can you tell us a little bit about when you’re thinking about requirements testing? What is that process like for you? So, like, actually breaking parts of the requirements and thinking about how to look at them and move them into the right kind of test cases.
[00:14:40.150] – Sergei Shvab
Yeah, it’s definitely very important to analyze provided requirements and to identify gaps. It’s very important to think from a user perspective what flows will be used in this application, which of them are covered in these requirements. And some people even say that when you are right in this case of analyzing requirements, you should put yourself in the user’s shoes. So you should understand what end user will be doing at this website or application.
[00:15:27.730] – Ryan Williams
That’s very important, actually. Right? Because you’re actually not just reading on the paper, but you’re thinking about how they functionally would use it. And can you look at the potential variation in actions or problems they’ll come up against?
[00:15:45.500] – Sergei Shvab
Yes, definitely. And also, when we are starting, for example, any project, it’s very important to identify exactly the audience of this website or application because, you know, there are a lot of differences between different regions. For example, what will be very famous, for example, in the US that cannot be, for example, such famous and important in Europe, for example, or in Asia. And that is why it’s really important to identify this, to identify, for example, a variety of devices that will be mostly used in the target audience for our application. And, of course, a really detailed review and analyses of requirements. And the creation will allow reducing the cost of each bug that will be found in this application or website.
[00:17:01.040] – Ryan Williams
That’s great. I have a question. Ana, I want to ask you this question. Thank you, Sergei. That was great. Anna, are their cases where the requirements are not written very well, and you must figure out more variation in the requirements. I want to ask is what happens when the requirements are not written very effectively?
[00:17:37.430] – Anna Melnik
Oh. I think that requirements are very important for all teams. And when we start this case’s creation, we are usually a quality assurance engineer, usually don’t have an application for testing at this development stage. So other words, you will start requirements testing before the application is ready for testing. And on this stage, the Quality Assurance Engineer starts to analyze all user flows for test case creation, and he will find these gaps if we don’t have effectively written requirements before we find the steps. And at this early stage, notify all team and business analysts, business users about these missing flows. And this will make the requirements better at this early stage.
[00:19:22.520] – Sergei Shvab
Can I jump in for just some words here and of course, on a bunch of projects that we’ve worked earlier and worked now, we are receiving such situations when there are a lot of gaps in providing requirements in such cases. Very effective is our understanding of best practices for a similar, for example, applications or websites, for example. And we can provide some kind of suggestions for the project team for the business team that, for example, in such a case we can implement flow in such a way and provide the best practices in this area, for example. And it’s always great to have some kind of a roundtable between the development team, Quality Assurance team, and product team when we are reviewing this requirement. It will help to identify or maybe not all 100 percent, but the majority of it, and it will definitely save the future cost of development and quality assurance in this space is really, really important, because if we are receiving insights into creation, that is not a really great requirement. It will cause a lot of issues in the future.
[00:20:59.610] – Ryan Williams
Yeah, no, I agree. Yes. Great. Thank you! Elena, I have a question when you think about that when you think about the requirements, testing, and collecting requirements and your building towards regression testing. So how do you track all of the requirements that come in and kind of accelerate the regressions testing process? So as you get them, you always know to go back? What process do you use for that?
[00:21:38.030] – Elena Shpakovskaya
For regression testing, right? Yeah. Form for regression testing, to create regression, run, yet we need to see cases created based on requirements.
[00:21:55.750] – Ryan Williams
So you collect the different requirements over time and then build the regression. Correct?
[00:22:05.170] – Elena Shpakovskaya
We collect requirements. Right? Then we create test cases. And when we have test cases, we can easily and fast to run our regression tests. And as the goal, I would say, of the skills development, accelerate regression testing. Yeah, because when we have to run this type of testing, it’s much easier to pick up tests from the already existing scope of test cases. Right? And I as a test run creator can easily assign the correct number of tests, not too much not too less just the correct number for regression run. And everyone from management, from the team can look into this run and understand what is the scope of our regression testing. Because in this case, in the steps in entitle, we always try to and describe very short and clear steps or description of the test, and you can easily understand what is a test about and what is the scope of checklists, this regression run defines.
[00:23:52.680] – Sergei Shvab
I just remembered I recall one golden rule here, you know, regressions which contain only the most important flaws, which can really block, for example, whole application or website. And it’s really important to prioritize the case when we are creating the cases, we are putting exact priority for each step in the case. For example, P1, P2, P3. and we can use any management tool, for example, it’s pretty easy to pick up, for example, P1 test cases and put them into the regression test run. And there is a golden rule that would reflect this case if we can treat them a good when 20 percent of the most important test cases can cover around 80 percent of all flows. If I correctly remember, people call it rule of 20 to 80, something like that.
[00:25:02.520] – Ryan Williams
It is the 80/20 rule, I think.
[00:25:04.240] – Sergei Shvab
Yeah, yeah. And it’s really difficult. It’s really important because you can create, for example, 1000 cases, but they will be checking just some UI have some people in text or something like that, but they can create maybe 20 cases which will cover a log in the registration, sign up, for example, checkout flow. And these 20 will be much more important than those 1000. And that is the main rule of creation and prioritization.
[00:25:45.230] – Ryan Williams
Yeah, yeah, that’s great. So just to be clear, for people who may not know exactly how the process works, so the Quality Assurance team gathers the requirements from the product team and sometimes engineering and they understand how these requirements are going. Are there are they have to work within the product to make sure that it’s technically functioning correctly and they take and assess those products and create pathing and flow through the system to basically mimic what that user experience is actually going to be like. And those are called test cases. So they’re actually creating test cases that run throughout the flow. And then the regression testing comes when you pick the kind of the most important of those test cases that always need to be checked as you’re doing releases on the product going forward. So in all of these cases, like understanding the product, how the product specifications are supposed to work at the foundation of the product, but also as it changes in each release, is really important because it can affect how you test it going forward, not just an individual test case for that release, but thinking about whether the product is stable through regression testing, correct?
[00:27:06.090] – Sergei Shvab
Yes, correct. Exactly. And, you know, this is called maintenance of test cases. And it’s very, very important to maintain them initial stage because this release, we are getting some new features, some UI changes. And if, for example, test cases are not updated and really important changes are not included in the regression, they could be easily missed and go off do a test run is to reduce the possibility of meeting in such cases. Because, for example, of course, if I, for example, a person who works on one project, for example, two or three years, I’m pretty familiar with this project. But anyway, there is always a chance for mistakes. And if you have disabled test cases, you can just you show them through life or on your brain. You just open this case, for example, what steps, if it’s pass or fails. And in such a case, if you thoroughly go through all the steps in this regression system, you will definitely be a blocker or critical issues. And that is one of the greatest benefits of regression test cases.
[00:28:33.180] – Ryan Williams
That’s great. Yeah. Thank you. That brings up my next question. Actually, Elena, maybe you can answer this one. Where how do you prefer to store these test cases for future testers? So once you’ve created the regression testing or as you’re creating new test cases, what’s the best place or the most effective way to store the information and share it?
[00:28:59.770] – Elena Shpakovskaya
You know, in my experience, I used several tools starting from Excel. Yeah, but it’s not convenient, of course. Google Sheets. And also, I worked with just TestRail and with the Xrays. It’s a Jira tool, but my favorite one is just real TestRail.
[00:29:32.150] – Ryan Williams
What do you like about what do you like about TestRail? Like what about it?
[00:29:35.700] – Elena Shpakovskaya
It’s convenient to use, it’s logically clear. It provides a lot of features such as reporting. Also, it’s easy to create different runs with different configurations. So for managers who create this blend’s, it’s very useful and very helpful features. and integration is very cool when you execute some test just case you can leave the test results. Yeah. And if it’s failed, you can create a corresponding back in Jira, and it will grace point in this case and you will see this and will be able to jump into the corresponding bug by clicking on this link. That’s very that’s great and useful.
[00:30:51.910] – Ryan Williams
So does Xray do something similar?
[00:30:59.260] – Elena Shpakovskaya
No, I would say no, not so useful and not so simple yet, and I would say fewer possibilities. So I would suggest TestRail, of course, from my experience,
[00:31:19.200] – Ryan Williams
that’s great. And Anna, how about which tools do you prefer for the test cases and regression testing?
[00:31:29.790] – Anna Melnik
Yeah, in my practice, I also started from Excel. And some of these cases were written in the Word documents, and I also tried TestRail. In my opinion, it is the best tool for these cases, creation, and management. It is really convenient and useful, contains all the required fields also it is really useful to organize the test runs and monitor the status of testing. And as Elena said, it is a really great feature that we have integration with Jira and you can easily organize the trustability between user stories and between test cases.
[00:32:48.710] – Sergei Shvab
Yeah, and maybe from a management perspective, this tool provides really great possibilities for reporting needs also, for example, with situations like certain. And on some projects, we had situations when our client doesn’t have access, for example, to testrail and we need to show him some results of testing or something like that, and it provides a lot of possibilities, for example, to create an export of test results in different formats. For example, in PDF is, for example, the ability to export. Test the test in the report, form test runs progress and test run for test plan for different features and they look really great. They are really clear. You can customize them for business needs, for example, because, for example, if you are providing a report for business people, it should be completely different in comparison with the report which you provided to tech people and says this tool provides all the possibilities. And also, as Ana has mentioned, it has a lot of integration possibilities and it’s really convenient. For example, when you go through a test run, you can see, for example, and identify a bug and you can start the creation of back right out of the frame. So you click a button and you go to great issue based in Jira in the same integration, for example, you can put different references to requirements to different issues or tickets in Jira, and it really helps in our daily work.
[00:34:58.100] – Ryan Williams
Yeah, that’s great, thank you. Yeah, that efficiency between being able to track the data and input it and then and report on it, but then also having it turn into an actionable item in the project management software is really, really helpful and effective. I love hearing about that. Well, listen, we’re actually out of time. I don’t know if you can believe it, but it’s been almost 40 minutes. And I know we have a lot more to talk about. We were going to talk a little bit about automation as well. But we’re going to wrap up right now. And I want to thank all of you for sharing your thoughts and feedback on the kind of like the foundations of QA, Quality Assurance, and the basics of it.
[00:35:45.590] – Ryan Williams
In the future, QA, Quality Assurance roundtables will go into more detail around some of these subjects and give kind of deeper, more intricate insights. But it was really great having you all here today. And maybe if you want to say something to say goodbye. Elena, let’s start with you. Would you like to say something as we head out?
[00:36:07.820] – Elena Shpakovskaya
Yes guys I was very excited to participate in this meeting. Thank you. See you soon. Great.
[00:36:15.980] – Ryan Williams
Thank you for your insights. We appreciate it. And Anna, how about you?
[00:36:21.110] – Anna Melnik
Thank you, guys, for giving me the chance to participate with all of you and share my knowledge. And I’m really excited to be here. Thank you so much.
[00:36:39.200] – Ryan Williams
Great, thank you so much, Sergei. Thanks for bringing the team and we really appreciate your insight. Do you want to say something as we’re leaving?
[00:36:48.220] – Sergei Shvab
Yeah, yeah. It’s really great to start this series of QA podcasts. And I hope visitors of our social networks will not judge us because it was the first attempt. We are not public people and it is really great that we have such an opportunity to connect with our followers to discuss anything. And we will be learning and to just comment on everything in our social networks and follow up. And thanks, everyone.
[00:37:32.530] – Ryan Williams
All right, thank you, guys, it was amazing. I appreciate it. And I’m excited to talk to you more incoming episodes about some of the other aspects of quality assurance and the test case process. Really appreciate it. I hope you all have a wonderful weekend. It’s Friday today. So have a wonderful weekend. And for all of you out there who are watching. We look forward to seeing you next time. Thank you very much for having us. We are Wonderment Apps we are located at www.wondermentapps.com. We offer two great lines of service. The first is managed projects where we can bring you a team of people that can construct really great software and technology. And we also offer a staff augmentation service line as well, where we allow you to work with our developers and they are just an amazing group, well-curated. And so we hope we have a chance to work with you in the future. Thanks.