November 8, 2015 at 11:04 am #9863RonanKeymaster@ronan
If the world was a blank slate and you joined a software company that had no testing, how would you establish the test process. Would you do it differently than you do it now? If budget was unlimited what would you introduce to a testing team? What processes would you have?
I would be interested in what approach some of you might take. I’m sure you have dreamed about this every now and again?November 19, 2015 at 11:10 am #10096Fiona MackenzieParticipant@fiona-mackenzie
I’m actually in this position now, started a new job 4 months ago in a company with no real structured testing and I get to set it up on my own from scratch. Any advice or suggestions would be appreciatedNovember 19, 2015 at 1:55 pm #10103MagnusParticipant@mange-pettersson
I’m also in the same situation and I have been building the testing function at my work from scratch. It helped that I have been in a very similar situation before where there was very little defined about the testing role and the routines and processes that existed were mere frameworks and sugestions rather than actual routines or processes.
I have found that the disposition of your co-workers matter a lot. “test friendly” developers save a lot of time where you do not have to convince them that you are not some kind of tornado that wants to wreck all the stuff they create.
You also need people (often management) to understand that testing is not a silver bullet. It will not solve every problem immediately. They also have to understand that testing takes time and that it’s not an assembly line process where you throw a bunch of work into one end and in no time, have results comming out of the other end. When these basic understandings exist on your company, you can start defining your processes. Try to get project managers, managers, developers involved.
These are probably the most important parts as I see it. I’ll be happy to answer questions.November 19, 2015 at 9:15 pm #10110JesperParticipant@jesper-lindholt-ottosen
“Quality doesn’t belong with the tester!”
We look at an example of a team that, learning to rely on the tester, ended up with worse quality than without a tester. We’ll also look at the practical steps of assigning responsibilities and pairing up and test automation effort that helped bring things back in balance.
https://dojo.ministryoftesting.com/lessons/quality-doesn-t-belong-with-the-tester-maaret-pyhajarviNovember 20, 2015 at 3:53 pm #10127MaaretParticipant@maaret-pyhajarvi
Jesper, thanks for mentioning me to draw me in. I don’t tend to follow these forums.
I’ve been in a position to introduce testing where it wasn’t as a separate function earlier in my career and I’m now 3 years into one organization. The story of that talk is that when every developer doing “testing” thinks “tester” will now do the “testing”, there’s a big chunk of what I call “programming” missing that lowers quality. It’s a risk to manage.
What processes to put in place probably would depend on the type / belief system in the organization. The structures I created were to enable freedom, trust and growth, and to my surprise, I’ve learned over a lot of pondering that we don’t need more testers than 1:10 to make the quality much better than it was without a tester before I joined. Quality tends to be about fixing and not breaking things, not about testing.December 1, 2015 at 5:15 pm #10199RonanKeymaster@ronanDecember 18, 2015 at 11:59 am #10355MichelleParticipant@michelleconway
I would start with the Develops work collaboratively with them on continuous integration tests. Testers approach testing differently than Developers and we can add value in this early phase by helping to construct tests which look at the layers behind the UI and include the database. through collaborative efforts we can build an always on regression suite of tests. If you have no testers this begins to get some testing in place
Now to the staffing, I would start with only a couple of Test professional’s and pair them with Business users. This does several things, up skill’s the Testers in the domain and the business on good testing practice and gives you business support since you collaborated with them. By working closely with the business they will eventually be comfortable with your testing and will approve changes with a short walk though. Then I would move onto Automation.
- You must be logged in to reply to this topic.