 So I think we can start. Welcome everyone to our session. We are very happy to see so many people in that late hour and Yeah, this is our presentation improve development process with better QA approach. Actually, it's about our experience We wanted to share with you what we are doing what how we are improving our development process and maybe some of these Deep streaks and advices can help you improve your own process in your company. Maybe as a QA members or maybe as other part of the Other members of the team. So we're starting with our agenda First of course, we will introduce ourselves after that and we will explain a little bit more details about why we decided to make this session because This is very important to know why and what is part such session After that, we will share with you our vision about QA twos Versus QA power and what we mean about power and after that we'll talk about the most common QA mistake from our point of view which is applicable in all companies not only in our company and After that we will share you Our secret of success how we are actually what we are doing How you can be better from our point of view, of course and how to deliver better projects with better process with On time with in the budget, which is very important and of course a little time for questions So let's start with introduction My name is Bushdar Bushnakov. I'm a rare manager in Gabriol. This is a small city in Bulgaria Where we have a whole production unit consist of 25 developers QA's front-enders and project managers I'm also head of the QA department in Bulgaria for FFW I was leading all automation activities all the activities of course for the QA department and all develop new processes for the company and for our department and This is actually one of the reasons I I've decided to create this this session for you to to share a little bit what I can from my experience and Here with me is my colleague. He will introduce himself Hi, my name is Tony I'm automation lead in FFW Okay, and Yeah, I have about four years of experience as a QA and three of them are as an automation engineer I have worked on for the one of the biggest projects in the company such as a wish cosmetics Nordisk film the Grofa Amnesty International and etc. And Yeah past the ball to Bushdar Okay, so yeah, Tony will speak about our secret later, but yeah, let's start With this one if you want to add some questions because our time is short as you know This is one of the short sessions Please join and swido on this link. And if you have any questions, you can ask them and we will Be sure that we will answer all of the questions that We have after the the session if we have time or after that Out of the room because another is coming. Okay, so this is the the link QA V from Vienna and The year yeah, so let's start and Why this session? This is as I said very important Question and why because I see that in many companies There are problems not with the development not with the skills of the people not with the ability of the QA's or the developers to do their job, but With the cooperation between them with the communication between them and with the process overall and I Think that we found a way to improve this It's not perfect, of course, and it's it will never be perfect but I think that we find found a way to improve the whole process and as a QA engineer specialist to Actually help the others do their job better and to help our self too To not report like a thousand books after the project is delivered and we have a Like two months for after the project is done to fix all these books and the client is mad. So yeah, this is actually the first The initial point that we started when we were creating the session and of course Here comes the the first thing that we want to share with you Actually, what for us means QA power and where is actually the QA power and the cure power is hidden in for us in this Five very important words, which all of you know all of you know that are important but it's about how we are Using them and what we are doing in order to have them as a QA engineers the first word of course is the impact. What is the impact of the Q engineer for the Development process as you know the QA is the one who is testing the system and verifying that the functionalities are working well We don't have any books with we are having the requirements Implemented in the right way and working almost bug-free almost, but the impact of the case not only the Functionality not only to verify that the code is working right the impact of the case should be more and more global We need to think what the client needs We want we need to think what the client needs to improve their business their idea Why they came to us with this project? What is their business? Why they did have before what is not working for them? what actually because To our company are coming very big projects very big projects with very big clients and they got a little a Little bit complex structure Maybe most of the time or always so we need to get into this structure and to realize What they want really not just how our developers? Implemented some functionality and this is the impact actually QA should start from the beginning of the project to the end of the project and Have impact on every each phase of the project not only in the development Yeah, I think is the involvement and this is about the involvement. We need to involve the Q engineers in the whole process I know many companies. I've worked with a lot of colleagues that said that they are just receiving designs For example, they are just receiving requirements and documentations which are already written approved by the clients and they just need to Strictly for them and to see if the developers are doing their job to implement Exactly the steps you see in the documents But I think that the involvement of the QS should be at all parts and when the designers are creating the designs where the technical leaders architects are creating the architecture or Working on the descriptions of the stories of the functionalities. We need to be there. We need to give our advices. We need to give our Concerns because they are very important. We can say, okay, this could cause us a lot of issues in future Please rethink about it or change it if if you have a better idea share with them. This is a nice Nice one and it is very very good Accepted by the clients when you share with them an idea how they can improve their business and I saw this in my experience The other thing is knowledge of course to be able to give such ideas to participate on such meetings like a technical architecture meeting or business Idea improvement meetings of something like this or discovery of the project you need to have the knowledge to be Capable of giving ideas or to be able to saying this is not right or You need to rethink this functionality because it won't be that useful in future. So the knowledge is something that we own it and as QA's we need not only knowledge about the QA specific We need to have knowledge about project manager activities about developer activities We need to be able to read at least code I can say that we need to be a half developers actually But we need to be able to read understand code to understand what the developers are doing and what everyone is doing because this is very important and of course the mindset the mindset of us all should be in the right direction we should not think of us like Some bad guys that will find all the books and say to developers You're not that good to not use another word We need to have the right mindset we need to help the others We are there to verify that the work is correctly done, but not by showing others mistakes We need to help them improve their self help them to be better And if we can catch something earlier, we need to show them not to see okay Maybe this in future will produce a book, but I won't tell them because after that I will report it And I'll be very nice because for one task I'll report like five books and I can say okay our developers Right and we are that good Okay, so the mindset is very important to and of course the responsibility the responsibility of the QA's is Also for the whole project. We are not responsible only for the things that are coming to our side We are responsible also for the deadlines. We are support Responsible for the quality of the coat of We receive not is it working or not, but the quality of the coat We are responsible also for the documentation that we are sending where it's possible also for the Communication that we have with the client This is also our responsibility as a Q engineers and we need to think about all these things We need to be aware of every step and every face of the project No matter if it takes if it if it is expected something from us Directly or not. So these are the things and of course the other side are the tools I don't say that the tools are not important. They are very important. Actually, we are losing a lot of tools Which helping us a lot But if you have tools without the first five words from our point of view Your job will never be enough and your job will never be Perfect or nearly perfect because This is the most important one the power These things are more important than the tools. Of course, we will say about our tools We will say what we are doing. Of course, we are building automation tests. Of course, we are making packages and so on but First of all, we need to think about the power and the power comes on this one So yeah, the most common QA mistake What what I have seen from my experience is that the QA's are added only At the face of the project where There are some ready tasks which need to be tested and this is a huge huge mistake from my point of view This is bad not only for the project not only for the clients not only for the development team But for the QMs themselves because they are not improving in this way They are just stuck in this situation when you are going to receive a task. You will test it You will find the books after that you will verify that and that that's it You your your job is done and you need to go on the next task No, when you're in the project this is about dedication. You need to think about the project You need to find the way to improve everything in the project not only the tasks and the most common QA mistakes is that the QA is not part of the whole process The QA is just a small part which is in the development process when the tasks are done Here I just took one one picture. This is the process. This is an agile sprint As you can see but this can apply for the whole project. These are actually all phases of one one project We have planning. We have grooming. We have meetings a lot of meetings We have sprint reviews. We have retrospective retrospective meetings, which are very important and Actually, I see that many times the QA is only in this section QA is stuck in the sprint execution section where we are just testing tasks reporting books after then after that we are Verifying them and that's it and that's it and that's it. This is very bad. This is very bad because for the clients I think that the QA feedback is the most important because the QA is the perfect position between the clients and the developers very often I see developers that are not able to explain in business understandable language why they did something why they develop this or why this is Hard to be implemented and they and the client need to needs to rethink it and Here should come the QA Who has the business understanding who has the business knowledge? to actually explain in the right way to the client what they need and Of course the technical background technical background to help him realize Which is possible which is not and how we can manage through through these distractions because these These are distractions every every time we have some misunderstanding between client and the development team. We have distraction which causes a lot of problems and In the better scenarios, we have the QA is also in the planning We have the QA is also in the retrospective meetings, but as I said, this is not enough we need to have a little bit more more impact overall on the projects we have and Here is the time to share our secret what we are doing and how we are actually Jumping in these other phases because it's easy to say we need to be everywhere But it's hard to realize it in the real life. It's Hard to find a place where there are no Defined tasks exactly for you assigned to you. It is very hard to find your place where In your company for example till now you didn't be You haven't been there and this is a problem and here we will share our secrets what we make in order to fit in these phases where I Think it's our place and now it's Tony Stern. He'll explain you more about this Okay, hello, so I imagine that most of you are working on Scrum and Agile So I will explain how the QA can impact the different phases of the project Let's imagine we have a project and initially we have a discovery and we have a product backlog creation then of course we have the design phase where some creative guys are creating something fancy and then we have some grooming sessions some planning some estimations of course then comes the sprint execution where Actually, the real work is happening and after everything is done. We've analyzed the project and we have to hand over it to the client or Some other company that's going to support this project. So let's start with the discovery phase What we have here the discovery phase is Actually one of the most important phases because this is where the development team and the company that's going to build a product He's meeting the client is meeting its requirements And this is the most important part to first the QA step in not only the technical leader Not only the technical architect not only sales guys because this is important This is the the foundation of a project then we have the initial clarification meetings that come right after They're actually a combination and they need to happen with all of the guys Then we have the the experience of the QA what this means because an experience QA can help the clients Clarify their ideas because they come with something we want to build this but the QA can Easily tell them you can build this but you can build it that way and this will interact with the users more and This will give you a better Better Process when you reach your end of life cycle and the product is done Then what we have we have the design phase. What means the design phase? This is where the creative guys are creating some fancy stuff, but what happens here usually but not Very often the design guys are thinking about the front end But the front end is the hard part where you make pictures reality Usually these designers are creating some fancy stuff that are hard to implement how I kill them Yeah, these are fancy and expensive stuffs. What this means that? Something very beautiful will cost the front end guy to be implemented like 20 30 hours And this is something expensive right here the QA can come in and say Because he's a technical guy, but he's also a business guy He has to understand the both worlds and he says to the client, okay This is cool. This is nice. You can have it But it will cost you a lot of hours and then the client can rethink, okay Can we have something that is less expensive, but looks as good as this one and this is where the QA Come in and get some feedback from the designer Then we propose something we have some meetings and everything is done. We have something fancy That is not so expensive Then what we have is the UX usually clients think of a product that it's something working and They don't think that Usually there are a couple of products usually there are some Internal systems that the client is going to use but in most of the cases they are building a product for the end user And this is very important to think as an end user because the client is Maybe some technical guys. They are not so technical. It depends on the client But we have to think as a non-technical people as a end user and this is where the UX part comes The QA can suggest improvements in early stage where for example, this is not going to work Well as a end user. They're not going to understand This it's very important for example for commerce shops. You have to focus on people buying stuff You know, you'll build your online market You want people to buy your stuff and you need to focus your UX on that for example You should have large and clearly visible add to cart buttons You should have large and clearly visible checkout buttons etc You should not focus on for example having carticles or something like this because your main goal This is an example is to sell your stuff. You build something fancy You want to sell it you have to you want to have billions of sales and your business to grow You have to focus on that and you need to focus your design of your website on this You want to sell for example, you may have a news website You want to focus on the article itself and on the content not on the other stuff, but Yeah, then we have to think about mobile devices nowadays. Most of the users are using the web through their mobile device It might be a phone a tablet or something like this, but most of us are using Internet on our mobile device and It's very tricky to fit a watch website. That's displayed on a computer to be perfectly Viewed on a mobile device. This is something to think because clients they're usually using computers to work They they also have phones, but they don't think this way. They usually Think of it just see presentations on the desktop version of the design But we have to think about mobile devices and of course we have to think about older Internet Explorer versions when something fancy comes in from the design But the client says we want to support E8 which cannot have this fancy design in it And this is where the QA can come and say yeah, you want this fancy thing But it's not supported by E8. Either we remove the Fancy thing or we remove the E8 and we all cross our fingers to remove all Internet explorers Yeah, then when we have what we have is some grooming planning and estimations This is usually where all the team members come discuss the tasks or write some technical descriptions write some the acceptance criterias together with the client and Where the tasks are actually born I'm talking about us because yeah, I assume we are working on a job Then what we have here is as I said creating of a task here The QA can go and sit with for example the technical lead and discuss the task this way The QA will have an idea what is going to be built for example in first print in second print and Have an idea what to expect to test because as we said QA should not be part only when the testing is Ready when a task is ready to be tested because this will He will not have time to prepare for example, you know that you are going to build some listing pages some Maps and you can research for example. What is tricky about a map? What is tricky about listing something like this? This is why the QA for example should take pay part of The grooming session then we have the sprint execution itself what we have here We have a lot of work to do. This is where the the thing is happening First of all, we commit to a plan. What is this plan? We we say that in two weeks for example, we are going to deliver 10 tasks But what means deliver deliver means that this task is completed. It's it's developed It's stout it's tested and there are no bugs But usually developers don't take that that way they think that we are going to develop till the end of the sprint But this is not the case because we have to force developers to think that there are other people after their work is done That need to style this thing that they developed that someone needs to test it Probably they are way with some bugs. We need to fix them. They may cost a lot of time So we need to push developers to Be done with the development As soon as possible because we need to they need to pass the task to the other steps Then what we have when a task reaches a QA, we have the manual testing which of course is Required for everyone. We have also the manual testing with Zephyr. What is Zephyr? Zephyr is a Jira extension I assume that everyone or most of you is using Jira as a task management system But we are using Jira and we found Zephyr to be very useful because it's integrated in it We don't have to use an external system. For example before we used test link There are other free and open source stuffs But we decided to go with Zephyr because it has really really strong integration with Jira. You have tasks in Jira. You can relate a simple test to a ticket and I will explain later what how it helps and then we have the automation tests What automation tests we are using? For example, we have BHAD framework. We are using BHAD It is a very famous framework for developing automation tests in the Drupal world because it has very strong integration with it. It has some extensions, it's built on PHP which is one of the most important parts that we are using it because Drupal is based on PHP and we have developers that know PHP well and when we face some troubles we go to them and ask them to fix them for us or help us to give them nice areas and Also what we have? We have backtrack This is a screenshot comparison tool which actually there are a lot of tools But we are currently using that one and building our own But it's what is doing when we deploy for example at the end of the sprint our Our new stuff that we built this sprint we want to compare if something has been broken So we create a snapshot before the deployment we deploy we create new snapshot What means snapshot is screenshot of the most important pages and then this tool just goes and compares the two screens and Show us the differences, but there are a lot of different picture comparison tools that you can use on the there are various tools on the net So and in the end we have a project handover what means project handover that We want to pass our project to the client. So we finalize it where everyone is happy Here what happens usually we should do a training and this training is best to be done by QA because if All the things that I have mentioned have been followed the Q will be the best person that knows a lot of the system knows How it works technically knows how it works as a user from a user perspective and knows how to use the system for as a Editor for example create content out new stuff, etc Usually the QA is the guy that is doing the documentation So I I think we think that the QA should be the guy that is going to do these three trainings to To the guys that are going to use the system and yeah, I think we are short of time. So If you have any questions Okay, okay, we'll be in the hall. Thank you Thank you very much