Read The Transcript:
We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.
Intro In the digital reality, evolution over revolution prevails. The QA approaches and techniques that worked yesterday will fail you tomorrow. So free your mind. The automation cyborg has been sent back in time. Ted Speaker Jonathon Wright's mission is to help you save the future from bad software.
Jonathon Wright This podcast is brought to you by Eggplant. Eggplant helps this test monitor and analyze the end to end customer experience and continuously improve their business outcomes.
Hey, Tatiana. Welcome to the show. It's really great to have you. And you've got one of the most interesting that we've had on the show. We started off at university doing law in Ukraine. If you've dipped into psychology, you're now a test architect. So please tell me, where did this all start?
Tatiana Zinchenko Hi, Jonathan. Thank you for having me here. Well, actually, it started it's cool when I've been there. I was really interested in computers, but, you know, it was the 90s, 80s, so we didn't have much of that. So.
But I always wanted to go there and actually have two masters of my criminal law degrees or the second one. And my first one is actually the one I wanted. And it was popular science. So I, I really, really wanted to do this since I was at school.
Jonathon Wright That's fascinating. My niece just finished doing law. And it seems like it's a pretty terrific area because everything's quite formalized is very kind of design, you know, a very kind of logical design round it. Do you find that it's a benefit if you doing kind of your keyway and testing with that kind of structure as well?
Or is there any particular aspect you've kind of pulled in from your kind of law? And also this good and intro to psychology as well. I guess there's a lot of cognitive side effects of how people say and communicate, you know, what kind of lessons to be learned from those kinds of university days?
Tatiana Zinchenko Oh yeah, I, I had a criminal law, actually. A lot of that, a lot of interrogation stuff. First degree, second degree, all the things you know. So now it's easier to get information from people that you want to develop as managers.
We also had the course, a special course about lying. If I don't know if you saw lie to me to be serious. It was my favorite. Yeah. So the TV series was actually based on the Book of Llanos. The guy was really, really smart guys, a guy. And we actually. Was learning from it, so, yeah, it really helps me now. And of course, all those detectives work, you know, when you're trying to get into Santee looking for small clues, etc.
So there are so basically what we are doing. Interesting. Well, and psychology. I started recently, maybe one or two years ago. I went deeper into psychology. So it's also a really interesting piece. And it really helps because nowadays, you know, it's not only a hard skill that you have to have to be a good professional.
It's also soft skills that you have to have to be a good professional. It's a combination of two of them. And actually, psychology really helps me to be softer. So that said like this, to understand what people want to understand, then the kid needs to talk to them easily and etc., etc. So things like that.
Jonathon Wright But it's terrific if you just highlight it, kind of those big kinds of topics. You know, it's basically like 90 percent of defects are found that the requirements to integrate interrogation kind of going, in fact, you know, getting clarity around from business stakeholders of what it's going to look like.
This requirements engineering aspect, which is kind of very process orientated to kind of understand what the youth is the business from. And I guess your ability to get it to translate that in your current role to kind of from a task architect. What do you do in your current role? What's the kind of feel your day to day look like?
Tatiana Zinchenko Well, now we have planned, so my day looks like a whole bunch of meetings, that's for sure, about. Well, actually he started that. It's almost a test to Steve, but we had more technical knowledge and we had more architecture knowledge. I didn't know how to say it in a different way. The most mostly.
Reviewing things, let's say, let's call it like this because I'm doing a lot of far are working with our product owners, with our developers, helping down to design our test frameworks for test automation, helping our product owners to do testing properly from their side acceptance testing, for example.
I'm directing o our developers to do proper test dimensions of the floor. We have a lot of unit tests. So I'm helping them build them. Of course, it's test environments. Did that. Our site did that. A test designed to colleagues because I prepare all, all the test scenarios in advance and etc etc etc.
So it's mostly thinking of all the or the whole picture, not only for one team but for the whole organization, how it should look like actually from the whole organization perspective.
Jonathon Wright That's going terrific. I remember there was this role which was called a project program test manager, and it was always this kind of idea of somebody living with that kind of portfolio level of responsibility, of fixing all the projects together and make sure they deliver.
But they did, you know, as far as delivering testing, you know, those design patterns which you're talking about, if you need somebody and I know you set up kind of QA, you know, departments before and put those processes and patterns in place. You know, you mentioned design patterns. What kind of things for you find that you have to work with the teams you're going to get them to develop, to implement.
Tatiana Zinchenko About design. All this. It was a good question. That's what I actually like to do, this analysis. There's a design all these things when you which you cannot estimate actually, because this is actually thinking. And this is the thing you should do properly because if you didn't do it in a good way, the whole testing afterward will be ruined just because it didn't predict this or that.
We should start from the beginning. And yet it requires a lot of time and we usually don't have that type. Yeah, well, testing requires a lot of time. Issues. It's actually basic test design practices, practices that they usually use of the well.
To some, there is something equivalent partitioning. Boundary analysis. Different types of decision tables, state transitions, diagrams. And I do know that a simple one. Well, let's say the simpler one, because we usually have our use, our experience to do arrogating or exploratory testing, which I also like, and especially this exploratory testing,
because usually, for example, before I came to my company, they thought that exploratory testing. It's just then you'll give something an application and say just test it. And it can be everybody like it can be H.R. or it can be a product owner or people without. Test the ground at all. But our company thought they could do exploratory testing and. Yeah. Well, now I'm here to explain.
Jonathon Wright It's amazing because, you know, part of that exploring aspect, I think you talked about some of those design patterns.
And, you know, I love Classification Trees. That was one of my favorites. And, you know, part of going through and doing the thinking aspect, which I think you highlighted, is if Kapiloff is within two and testing if FTP the thinking ahead of time or even start asking the right questions for the right people.
You know, a bit like you said, with the investigative kind of figure, if you know, part of it is this so many different sales of people who take this information in a process in different ways, you know, to figure that across a large organization. You know, I know you've been the past few years, things like the Spotify model and so forth, but you see that you're doing more work with kind of scrum of scrums, kind of, you know, scaled, agile kind of practices.
And if that knows your role within that cause, you know, what are the roles. Which I always look for in our organization, that they seek to be BC if you know the idea of this kind of solution architect, you know, you have the foolish enough take to understand how all the pieces come together. Used to be called enterprise architecture.
We bring in a test architect into that role, kind of give that same kind of capability across the organization to say in your role, you're able to support bringing those pieces of the puzzle together and making sure that it's not just one extreme to the other. As far as if it's a regression if you just automate this unit testing, you know, part of what you've done in the past where you've kind of had to do a code freezes and environment freezes and been kind of the one who has to step in and kind of say this can't go to the next stage or not. Do you feel that that kind of that role, if it needs that level of seniority within the organization to actually be able to help organize the success of testing?
Tatiana Zinchenko You know, yes, I feel this pressure on shoulders, but that's for sure. And just today, I had the meeting get our other test architect in our company. He works here for four years or something. And, you know, here's that senior that it's this. He started working at ninety eighty-two. I guess it.
SEO that when I was born and he already was thinking about all this stuff and started working and seriously he is so smart and so experienced that I have. I have 14 years of experience in testing, and I felt like a little baby serious there. So, yeah, that there is a really senior position and you have to know a lot of different things.
Like you said, starting VRT, technical knowledge, did the release process with all the methodologies of creating software via automation tests, things, tools, applications for all of those things. You have to know a lot about programing language, just about the databases, about tools for CI/CD like every see.
So you can see the whole picture and you can actually help other people because like you said, a test architect is putting all those puzzles in one in one place. And this is really important to them to have this broad knowledge, to know to work successfully. Absolutely right. Yes.
Jonathon Wright And I think that's really interesting because, you know, part of it is, you know, some organizations will have challenges of scaling QA and testing, especially in local organizations you work in at the moment. If you're part of it if you like the city. So why. Yes. So but you've got to look at the full big picture. And, you know, there are not many people who look at the big picture, everybody in silos. I was looking at an app or a piece of paper built to feel a product that they're building.
And it's very rare that people have the view of the big, big picture. I know that from you what are my favorite things about your lengthy profile. You mentioned that you know, they apply for you to work. You get called you the queen of QA, which I think is maybe potentially get a debate that the podcast, that title.
But, you know, part of that was you were happy to engage with the people at the CTO, you know, disagree, you know, challenged. That's really refreshing because part of it is you've got to have confidence. And I know, as you said, 60 years, you know, you've got to have a certain level of seniority to feel that, you know, it's worth, you know, questioning.
Why that why people are asking why, you know, if that is something that you practice every day or if it was that, you know, with your queen for QA for just a day, or was that a long period of time?
Tatiana Zinchenko No, that's that was an interesting story. DevOps the tune of QA. Of course, it was a joke, but it was a joke from BI when the chair back then and I decided, yeah, I'm definitely going to put this joke on my LinkedIn profile because it looks so funny.
But I'm talking about being confident about my decisions. Yes. That you're absolutely right. You have to have this all this knowledge to be confident in what you're saying and what you're deciding about. Also, I'm always open to discussion. And that was one of the questions in a job interview, actually, because they asked me if I am confident in my decisions all the time and what will happen if something someone will come to me and say, no, I don't agree with you and your decision. And this is just this is not right. you're doing all the wrong.
And what are you going to do? And of course, this is the other part of your job. It's not only being confident in your own decisions but also be open to other opinions because I don't know anyone who always writes older people, the old might make mistakes all the time. It's not only developers who will make mistakes, but we A/B tests theirs also make mistakes. So I can also be taking something. And that's why I'm always open to a good discussion and for a good opinion from some from somebody else. It really should so completely opposite to what I do at the moment.
Jonathon Wright I think that's a really, really impressive kind of way to look at these things.
And, you know, I think part of testing and I don't know if this is a certain camp, but, you know, I think especially with automation, I suppose they can be quite precious about, you know, a bit like code, really precious about your code and criticize. You say, you know, they're criticizing you, but at the same time, you know, things evolve. You know, it's evolution, not revolution.
A part of it if you know it's not a big bang and change all the processes and that will sort out the organization. It's evolving those processes together in a direction that works for that particular organization. And that's one of the things I think organizations find really hard because. They take some to, like, disqualify model and apply and think that will fix the problems.
And that doesn't always need to have an open-door policy, which is kind of what you'll say in there, where people can come in and have a discussion and challenge the idea around the principles of what it means to be QA within your organization. I think that's a really fresh way of looking at things because, you know, we are used to these ivory towers and just people building these things out from a political stance so that they can, you know, have more people reporting for them or, you know, more budget allocation.
But in actual fact, that's not what it's about. It's about, you know, developing and improving things for the good of the entire company. And, you know, it sounds like what you've been trying to do is try to help them on that journey, but also give that kind of fresh, that challenge as well and that kind of feistiness with which is really, really good. One of the things I was always really impressed with.
I remember a project manager who was two types of project managers. So BI in the past, there's one which, you know, was a technical project manager and would look at the technical detail and kind of look at the information and make a decision based on the technical stuff. Sometimes those technical decisions that underneath them are made by their team or BI be made by architects or whoever. They then kind of critique that and kind of go, well, you know, I don't think we should go because it's too technical REST.
And then this the other project manager type pretty, but it doesn't have the technical experience and tariff then looks at the information based on the information that's gathered and makes a decision based on, you know, the likelihood of the issue occurring. And, you know, makes a decision which is more with the heart than you know, than anything else. Now, how do you fit -- Because you've obviously got that technical expertise, you know, looking at some of the stuff, the tooling you've used the past. You know, it's quite complex that, you know, how do you keep yourself kind of between the two or, you know, what is your track?
Tatiana Zinchenko That's a really good question. Actually, I. And it's a really complicated one. Thank you for it. I don't know what to say because I already have this technical knowledge and they always use it.
But I also open the discussion, so if you can defend what you're saying and what you're thinking. I really, really appreciate this. You know, this is also a good topic to discuss, because usually when you're saying some things to somebody that your idea is not really good or somebody tells you that the lady is not really good, and that's actually why it was psychology course, because soft or soft skills, you know, usually we cannot determine ourselves from what we are doing. And usually, it is actually in real life.
That's. Completed two different things. Me and what I'm doing. And if somebody comes to me and says, OK, your project is not really good, your idea is awful. Usually, when somebody is hearing that, it's like, okay, you're a loser and you suck. But that's not what people see. They actually say on there about what you did about your project, not about you, but because you have this thing in mind.
It usually leads to confrontation or something like that. And this is why I think it's important to have those soft skills in you because you can determine one thing from another and be more open to the discussion of all those things. So, yes, of course, I use my technical knowledge all the time.
If especially when developers tell me things like, oh, we're going to finish this in three months and then like now, guys, you're not going to finish this in three months just because I know for sure for a while, like the past experience, that they're not going to finish this in three months. They're 100 percent.
But also, I'm open to discussion, so I will absolutely give them a chance to prove that they're right and they can actually finish this in three months. They well, of course, I'm not going to tell them I told you so because I had this as a college course. But I will definitely think like that. Yes.
Jonathon Wright I, I think because retrospective, you know, this idea of retrospective learning from the lessons, like you said, you kind of know the characters which you're in, that you're kind of, you know, ambition, which they may have to get things done in that three month time period.
But, you know, you know, historically, from the challenges within your organization, which could be cultural, they could be technology-based, which you've got to be overcome. You know, it could be how easy it is to get through the relief process.
You know, you understand what the barriers are to success is. And part of it is you setting the right level of expectations for the business to understand. Yes. You get a bill, you know, you're not going to do it on time. You know, that kind of technical knowledge if you kind of has to achieve over time. Yeah.
What what do you find is the best way for you to learn to visit? You know, it online if you know if it courses. What's the best way that you found kind of upscale yourself? If there's a new technology that you have to look Lokar or a new type of soft or hard skill, you know, if you have any recommendations for people, they'd like to learn.
Tatiana Zinchenko Well, usually I start by myself doing something if I want, for example, to learn a new language. I usually start started some of you do because or Corsaro or something like that, just to get the basic knowledge. But then, of course, when it does go deeper, I need a mentor. I never a go-to mentor.
Then I know nothing because it will be just ridiculous. I will take a lot of time from a person who really has something to do except this. So usually for the simple, simple, simple stuff, I start by myself because you can learn it everywhere. Basically everywhere for free, for money, for, for whatever, whatever you could find.
But after that, I really, really need a mentor and some well-experienced person. So that's how I usually things.
Jonathon Wright It sounds like a really good idea and a part of going and finding somebody within the organization you've already established.
You've got a basic understanding and that maybe they are more willing than because you wanted to learn to actually help you. And that seems like a really good idea. If so many you know, it's daunting for the people who are just starting Alphen, their testing journey that there are so many things going on.
And if that level of experience that you've kind of developed over time when you know, you know, subsid needs your attention or you need to focus on that from, you know, focus your efforts on, you know, if they're any kind of signs you see from something's happening, whether it be, you know, lots of defects or maybe, you know, there's a lot of kind of issues and a lot of check-ins what kind of things you follow when you're doing you kind of daily stand-ups and if you can, with the teams down in the trenches.
Tatiana Zinchenko If I understood your rights, you're asking me when they stopped testing.
Jonathon Wright For, well, where you start weight, where you identify to start testing.
Tatiana Zinchenko To start. Usually, I start testing when we have requirements. So I start testing with requirements first. Usually we even in requirements you can find something. Something is wrong because, for example, in point one says we should have a blue line. But point. Freeh says we should have a blue circle and you can find things like that in almost every requirement, you know, you read every time, and this will save you a lot of time if you find it on the requirement step actually in the requirements stage.
And, of course, then if you have a prototype, I can test prototype. Then we could create some background API. We can start with that. And of course, then et cetera, et cetera, et cetera. So we continue to continue getting to the testing we all used to. And they all do an everyday recall or regression testing, acceptance, testing, release and so on and so on.
But yeah, usually I start with requirements and when I come to any company, I had some practice in my career. Every time I ask at the board stage, usually testers start to work with you guys. And almost all companies usually tell me, oh, we have requirements, stage and development and then test starts. But that's not right. It's like you're not working in Java or a new mother's environment. But tautologies, you just make small waterfalls one after another. And
This is just not right. So I usually try to be a part of planning meetings. I usually try to be a part of the design meetings. I usually try to read the requirements before they go to developers because it usually saves a lot of time. It saves a lot of time for my future testing for developers to develop because you can develop at the same time.
Blueline and blue circle, it's just impossible. And this should find this before we start testing and before they start developing. It will save them time and money. A lot of it does a lot for your company, for the team.
Jonathon Wright You know, I think given shifting early into the lifecycle and doing requirements, you know, requirements, engineering practices, something that people skip, actually listening to what you said, that it was quite interesting because, you know, been the barrier in front of the development, getting their hands on a requirement. So it doesn't matter what that requirement is.
Let's just say, for instance, this story just set this up. And if not complete. Right. There are no acceptance criteria or if it's missing the clarity me, there is a temptation, especially for developers and the time precious that the ratings are if someone says to create a blue line, you'll go off and do a blue line. Right. But the thing is, then they come back in.
They've got a contradicting kind of thing. So it's ambiguous kind of requirements come in. That doesn't make any sense. It's also asked for a circle now. You know, parfaits. What you really need to be is that person in between to stop all that rework that's going to be done as things go too far down the line. And I think this is the problem, the dissipation of, you know, getting things defined quickly and maybe it's done repairing, replanning or something.
During a ceremony of some description that actually the clarity is not there and it's not actually ready for development, you know. And that kind of stage where you're kind of QA before it gets into ready to be developed. Is that another potentially is a great place to actually kind of put some structure around? I think that's really interesting. So you know, I've not seen anyone do that kind of approach.
But in actual fact, there's a lot of rework that saving people down the line. If you're able to get in there earlier and make sure, you know, it's ready to be developed, and it's at that status instead of just people going go to Ho and just going and trying to implement everything straight away without any kind of artist architectural decisions being made about what it should look like from not only the solution architect for the people who are doing, you know, the technical development leave, but actually the testing architects and testing the well. So that's a really good point that you've highlighted.
And, you know, I think it's interesting that you kind of you with that experience that you've got, you're able to kind of have that kind of wisdom to start earlier on in that lifecycle and understand kind of visualize what the big picture should look like. You know, do you find that within the agile process that they're doing, that they the descriptions on as detailed as they should be or you know or you know what what what are you finding at the moment?
Tatiana Zinchenko Well, you know, this is true that in agile environments, the house requirements changing not all the time, but they can change, that's for sure. And acceptance criteria, yes, they should be added to the tasks, of course. But also we have the scene like confinements every now and on. And I, I tried to be a part of refinement before it happens. So different Fineman's a day or two.
I usually ask our brother Toner to send me tasks this year. Are we going to work this during refinement? And I go through those tasks and I am trying to test in advance and to see how I will test them. And if it makes any sense and this doesn't make any sense, then we can do something that probably the assignment is not right or maybe ours. Previous decisions were right.
So I usually go back to the documents that they have and then I compare them with the tasks we have at their assignments right now. And if I have anything which is not right, I usually go to product on and ask them what is right, this what they have before or this that they are having now. So, yeah, I'm trying to reduce the disturbance in the force as much as I can. But yes, of course, you're absolutely right. The house requirements are changing. This is what has in the jail environment and or fortunately.
Jonathon Wright And it's interesting that you say that because, you know, part of traditional waterfall models, you know, you would be used to things like change requests. Right. Which are quite formalized? You get in there, you realize what needs to be changed. You make a change. And that impacts, obviously all the code and everything and it gets done. But, you know, quietly with agile, what you're doing, if you may be a court, you know, you're halfway free from product increment and someone changes it Chromium. But, you know, that requirement has now been refined and split into 20 different tasks.
Which one could be architectural, one could be, you know, a capability that they needed. And it will impact all of those. But requirements, traceability used to be something which you could visualize, whereas now the complexity fuge. And I think that's probably one of the big challenges with that. I know people you sort of used the word fragile. But if you know you've got a challenge around change requirements, I think what you're doing there is actually you're working out if it's testable ahead of time to work out actually maybe before it goes into refinement.
You know, we need to get some more clarity from the maybe the customer or the business owner to get understand what it is and catch those things before they end up being a change request where someone says, no, I don't want a line, I want to three circles. But I told him the day after it was a circle instead of a line, and he put both of them in. The requirement is wrong. So you're Parfit if you're cashing those things earlier.
And also you're stopping the disruption on the teams that want to get into refinement and want to start, you know, that fact software factory model. But if you're protecting them a little bit from, you know, going too far down the line and having to redo it, I think that's really interesting. So, you know, supporting change requirements, ever-changing requirements seems like something that you probably are quite used to now.
And also, from an architectural perspective, understanding whether or not a festival. And also if it is feasible, working with the rest of the leadership team, I guess, across that board, you know, does that require you more to work closer to, say, for the development architects as well?
Tatiana Zinchenko Yes, I usually work with the whole team. It's not the only architect, but it's also not on the project, on our product, on our chairs, dev team, test team. So, yes, I work closely with all of them. And I usually not on managing, but I know a lot about our application and especially what you mentioned before, is that the stability of the application, because, for example, the previous project that I just came, they already hired a couple of professionals,
but the application was absolutely not testable, like Ops not testable at all. And I spent around three months trying to get it on the stage. Testers actually did start work on this and started testing this out. The stability is really, really important here. But also, you know, I'm really noisy. So I love to get everywhere. And if they don't want me somewhere, I, I go there anyway.
So that's why I usually the most knowledgeable person in the team. I know a lot about the project of, about process, about requirements, about everything. And that's actually how I got the queen of QA title because that's how it was after I started onboarding our new product order. And he saw all my knowledge and for everything I've done for the team. At some point he said, Oh, yeah, you're doing okay. Yeah. That's how I got this.
Jonathon Wright Well, it's been lovely talking to you. Testing royalty. You definitely the Queen of QA.
Slack for those people who aren't maybe princes out there, we would like to out of contract you. And keep in touch. You know how the reef waiting to get in touch with you and you know you have Twitter or what's the best way to connect for those listeners?
Tatiana Zinchenko Oh, I don't have to there. I'm sorry. I have LinkedIn I am a co-organizer of the Amsterdam Meetup. So if you're in the Netherlands, welcome. And what else do I have? Oh, I don't know. Facebook, so please reach me there. But I don't have, I don't have Twitter. I'm so sorry.
Jonathon Wright No problem. No, they've been actually fantastic talking to you, and yeah. We'll have to keep you posted on the Queen of QA progress and in your new role.
Tatiana Zinchenko Thank you. I'll try not to disappoint you.