Testenvansoftware.nl
  • SOFTWARE TESTEN - Blogs
  • SOFTWARE TESTEN - Older blogs
  • Wat is software testen?
  • Links
  • C# programming language
  • Testing on Youtube
  • test tooling
  • Test Process
  • a test syllabus
  • Ik zoek werk
  • Robot FrameWork
  • coins
  • SOFTWARE TESTEN - Blogs
  • SOFTWARE TESTEN - Older blogs
  • Wat is software testen?
  • Links
  • C# programming language
  • Testing on Youtube
  • test tooling
  • Test Process
  • a test syllabus
  • Ik zoek werk
  • Robot FrameWork
  • coins

How to introduce QA in a company? [part2]

9/5/2022

0 Comments

 
When at first, 100% of the Scrum stories were about the development process of the application in the sense of coding. Now with the QA process introduced especially the Product Owner has to take into account that some of the tickets for the refinement will be for progression of the software process.
That is a big change in work orientation for some of the ICT fellows.

Also, when QA is introduced more formally than in many cases there was "always some dude that actually tested the stuff", but he was never formal a QA/software tester. This means that there are persons with a ton of knowledge about the application, but the knowledge is in their brains, in the head.
But that doesn't mean that the newly introduced QA people don't need that knowledge, so there has to be reserved time to transfer that knowledge.
That reserved time must be something that is very firmly and certain, it should not be something optional.
Also, when it gets complex it should not be the case "this dude" says... oh let me check this quickly for you, so the story can be dragged to the 'done' column. NO! There must be(e) cross-pollination of knowledge! Knowledge transfer to the new QA('s).

Picture
More items related to software testing should enter the Sprints.

Next step is to Scrum poker those software process related items.
Bring them on the table.

What I unfortunately have seen a lot is that a QA asks for a certain functionality in the software to help the software testers check quicker for a certain correct functioning of a module or functionality. But that request gets shot down by the Product Owner (or others) because 'other things are more important'.
Then what you see is some recurring patterns.
1) When finally that request is met (coded and pushed into test environment(s), it is many times especially the users of the information system that really like the new functionality. (not only the testers that asked for it)
2) The requests are not fulfilled, but the nagging about the throughput time of the functional/regression testing starts in heavy amounts to enter the podium.

Picture
All in all, hiring software testers and/or a QA Manager in the company and thinking everything will work out just fine automagically is not a good idea.

You really have to do this aware and thoughtful!

0 Comments

How to introduce QA in a company? [part1]

9/2/2022

0 Comments

 
There are company's that are advanced with software testing, and there are company's that are starting with software testing.
There are company's that have a gigantic budget for hiring testers and there are company's that have almost no money at all to hire at least one tester.

That having said, let's take an average company that has 1 application and 5 developers.
They start with the first QA Manager in their team.

Well now, there has to be some kind of rules so the QA Manager starts writing a test policy (in Dutch: testbeleid).
Picture
What you soon start to see is that the 5 developers had their way of working and for some of them it is hard to adjust their way of working and play by the new rules (of the test policy). So the first aspects that arise above the horizon for the QA Manager is... change management aspects.

Picture
As the new QA Manager you can't just say, "hey I wrote down some testpolicy rules but whatever, just put in production how you want it and what you want, it doesn't matter...." no that just don't work that way.

Just like driving a car in traffic, you will have to obey the rules. You've got to follow those rules.

So now what you need to understand is that those test policy rules you wrote in the document can be very strict and formal or a bit more loose and easy to life by.
Picture
It can be the case that in a certain company (everything is actually context dependent) the need for them is actually for very strict test policy rules. They are actually in need of a
Release report before a new version of the software product can be installed on the production environment.

But if developers were not used to that, then the gap between how they used to work and how they are going to (for their feeling) obey the rules might be very big.
They can get the feeling that they can't adjust to such big differences in such a short time. 
And in some cases, the
QA Manager will experience that they either can't do it or they will not do it. So that is a big challenge. 

Picture
 What you will notice as a QA Manager is that you just can't turn that knob, you'll have to be sensitive and maybe introduce a little more formality step-by-step.

Then the questions arises okay but there's so many to write in the test policy, with what do I start first?
​
It's important that you make clear to the developers okay guys you had a way of working where you decided how things did go, but since you want to do more with QA, now you got to understand that things are going to change. And it might be the case that you don't like it, but that's the way it is going to be.

Consider the following: a fictive country has roads, cars drive on those roads, now they need traffic rules, but wait 5 humans (coincidentally developers) in this country want to drive whenever they want and however they want, they say they are in no need for any traffic lights of whatsoever... hmm that would be a strange situation right?

Well the same goes up for introducing QA in a company, either you do it and you do it right, or you don't do it at all (with all the consequences included).

Picture
One of the biggest changes for the developer is the aspect of time management. Let's state that 8 hours of a working day they were able to spend on coding. Now suddenly there is a QA that starts asking all kinds of questions. But the developer wants to write code. 

That's not very cooperative towards the QA Manager, you could say.

Well there's also a more formal way how to see this:

Let's cast our imaginations back to the example of the traffic rules in the fictive country. Suddenly one of the 5 developers gets stopped by a traffic cop.
Wouldn't it be a strange situation if the developer says to the cop: I've got an appointment with the barber, sorry, but I'm not going to answer your questions. That wouldn't be allowed right?

What you see many times in companies when QA is introduced is that people have to get used to the fact that suddenly there are people that start asking questions about their work. For some people, that can be such a big change that they can't even get used to that within a certain time span in which it is actually needed. (for example, the QA has to write that release report and the QA Manager doesn't have the status update of the module the developer is working on).
Another aspect in this is 'timing': so sometimes the moment where the QA needs the answers to his questions is exactly the moment where the developer is in deep focus with the logic for the code, yes that can be the case, still it can be the QA can't stay too informal with it. Sure he can postpone his question sometimes, but the developer has to get used to the fact that maybe 5 minutes of talking to him can get the QA going with the testing for hours, maybe even days in some cases.

Another aspect when introducing QA for the first time in a company is that many people don't understand how big the pallet of topics is that a software tester can come in contact with.
So what happens is they want that the QA starts regression testing, functional test, write automated tests, assist with the User Acceptance Testing, security testing, performance testing, database testing, it gets to the point that all those tasks can not be done by 1 person anymore. (and the QA is in need of even more rules in the test policy document f.e. a Test Risk Analysis session (scoping his work and planning) but the group hasn't even adjusted to the current test policy's yet (dilemma)).
​

Then budget aspects come into play as well. If a company has almost no budget for 1 QA (or what sometimes it happens they have budget, but they just don't want to hire another person (" even more traffic cops? pffff ") but the demands for the amount of work or test throughput time are completely unrealistic, then it can get to the point that a QA engineer gets frustrated.

Hierarchy
What you see many times when QA is introduced in a company is that the hierarchy (who reports to whom?) stays long the same way, but not the way it should be.​
Picture
?. Everybody understands that a traffic cop doesn't have to report what he does or why he starts asking questions to a driver of a car. That the car driver is older than the traffic cop is not an argument.

In companies, however, it happens many times that the new QA has to report to the lead developer (or other team member for that matter). Which in fact is completely nonsense, it doesn't make sense. Because he is longer in the company should be seen just the same as an invalid argument as "the car driver is older".

It gets even worse if the QA is taken accounted for when bugs show up in the production environment. 
0 Comments

    software testen

    Picture
    Picture
     

    Uw banner ook hier?
    Tweet @testensoftware
    Follow @testensoftware

    Archives

    March 2023
    January 2023
    November 2022
    September 2022
    August 2022
    July 2022
    May 2022
    January 2022
    November 2021
    October 2021
    May 2021
    April 2021
    August 2020
    July 2020
    June 2020
    April 2020
    March 2020
    February 2020
    January 2020
    May 2019
    February 2019
    January 2019
    December 2018
    November 2018
    October 2018
    July 2018
    June 2018
    May 2018
    April 2018
    March 2018
    February 2018
    July 2017
    May 2017
    April 2017
    March 2017
    December 2016
    November 2016
    August 2016
    February 2016
    December 2015
    September 2015
    August 2015
    March 2015
    February 2015
    January 2015
    November 2014
    October 2014
    September 2014
    August 2014
    July 2014

    Tweets by testensoftware

    Author

    Motto:
    'Quality is a choice!'

    Categories

    All


    Foto
    De beste boeken over software testen...
    Foto
    Wat een tester nodig heeft...
    Artikelen over software testen... in het Nederlands: infonu.nl
    Picture
    Teach2000 - overhoorprogramma

    This website uses marketing and tracking technologies. Opting out of this will opt you out of all cookies, except for those needed to run the website. Note that some products may not work as well without tracking cookies.

    Opt Out of Cookies
Powered by Create your own unique website with customizable templates.