1

Background:

In my previous jobs, I was Software Quality Assurance Engineer. The recent company had many running projects, I was QA for 3 projects, did both Manual and Automation Tests. We did Scrum, so we had Daily Standups every day involved whole team (BE, FE, PO, QA). And as QA, I had directly worked with developers, ie. direct discussions, planning, etc. Which I really liked this way, and I am used to Scrum.

Situation: I try to describe it as much sense as possible

I have started my new job for 2 months, as fully Automation QA Engineer (it's like Developer in Test), it's my first time doing 100% automation tests. The company has only one big market product, which is very successful. We have BE Team, FE Team, and QA Team, but we don't have a team lead for each team, instead we have a CTO on top of everything. And we do Kanban (another first time). Once in a while, the CTO gathers all team members spontanouely and says we are doing standup now, to give updates on what's going on. So we don't have much interaction with each other. Only when Manual QA members do testing, they will interact with FEs or BEs if they find something.

And for me, as Automation Engineer, I have much less interaction with develpoment team. And as I mentioned, we don't have team leads, so so far I have only discussed/worked with one (kind of) senior Manual QA. She would tell me which features could be helpful to be automated, etc. And then I would do it alone. I am not involved in planning meetings, for example, but the Manual QA members are. So I don't know which features are being implemented or something like that. We don't use Jira too, we use Redmine (another first time)

Questions:

I know it is a new company, new environment, new structure, new role and all, but I am still a little bit worried about the career path I am heading to. Needless to say, I do love Automation, but I would also like to have interaction within the team (like I had in my previous jobs). So my questions are:

  1. In Kanban, is it normal that we don't have that much interaction with each other like Scrum?
  2. And as an Automation Engineer, is it normal that I don't have much interaction with development team? Or is it normal that I work alone as Automation Engineer?
Improve this question
8
  • 1
    I had something like you in another project : development team on a site, QA in another (no validation though). When QA validate, they submit ticket to the project manager that dispatch them. We could ask for clarifications but generally because QA is also busy, it's the project manager that would handle those demands of clarification with the QA team. On the bright side, it avoid the project manager to get bypassed on the other side, you may lose a bit of time. What kind of interaction would you expect from the development team ? Tests should be known from spec and UI design mostly.
    – Walfrat
    Commented Apr 24, 2018 at 14:09
  • My last company sounded like your, the manual testers were in the team with dev and they produced test scripts for the automatic testers to script, who never really spoke to DEV.
    – WendyG
    Commented Apr 25, 2018 at 11:01
  • @WendyG What was the outcome of this at your last company? Did automatic testser say something? Or was it OK for them? What did the team think about that? Sorry for many questions, but I would love to know because this is the situation I am in right now. Thanks
    – Ragnarsson
    Commented Apr 25, 2018 at 11:25
  • @Ragnarsson Everyone accepted that was how it was as far as I am aware, everyone on the automated team had been there years before I joined so all discussions were years before me. BUT they did get very detailed test scripts to work from "press this button" "expect 24 in that field" style of test scripts
    – WendyG
    Commented Apr 25, 2018 at 11:31
  • 1
    @Ragnarsson You need to talk to your line manager, I presume you have standups say "lack of business knowledge is a blocker for me" or some such think
    – WendyG
    Commented Apr 25, 2018 at 11:50

3 Answers 3

Reset to default
4

For question 2.

It's a problem or not, depending on the organisation. What you need as a test scripter is proper specifications of what to test, and a good visibility of the evolutions of the software that will impact your work.

So the real question is : are you correctly fed with those 2 informations? I know I am well for the first part(specs from the functional team are excellent), but not on the second one(release notes are basically impossible to use to know what script has to be maintained, in our case), and it's a problem for us.

But wether the information comes from the development team, or any other source, is not relevant IMHO.

For Kanban, no clue.

Improve this answer
2
  • Unfortunately, as the Senior Manual QA said, we don't have good documentations. We have just gone through what Manual QA members do for every releases, and we define which features/regressions should be automated, ect. So no, I don't have a proper specs :(
    – Ragnarsson
    Commented Apr 24, 2018 at 13:23
  • So you need a clarification on wether your role includes the design of test script(and not only the coding part). If yes, you need training from the people who know the software and the functional parts.
    – gazzz0x2z
    Commented Apr 24, 2018 at 13:53
2

Is it normal? Well, it is unfortunately common.

Is it good? Probably not.

Kanban is less rigid and prescriptive than Scrum. That's good, for a mature Agile team. However, for an immature Agile team, less isn't more, it's just... less.

The agile manifesto values:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And in my experience, that has positive benefit for a software development organization. It sounds like your organization, possibly due to rapid growth (just the CTO trying to be a CTO, but also apparently manage everyone and even run standups, is clearly not able to spend time at it) is happier putting folks in silos and running.

The good news is, you can have a part in changing this. Show initiative. There's nothing preventing you from "talking to a dev" but you! I'd imagine that not participating in planning and knowing what features are coming provides for a significant gap in automated test coverage; keep those metrics and advocate with your teammates and CTO for closing that gap via closer collaboration.

Improve this answer
2

This response is after conversation in comments. I know scrum not Kanban so sorry if some (or all) of this is useless.

In my previous company manual testing was embedded in the DEV teams but automated were external as they covered many different products. Our automated teams got very detailed test plans which you don't.

Your first port of call is your line manager/ immediate superior and talk to them about your problems. But come with solutions (it is a horrible truth that people like you coming with problems and solutions make their job easier)

so here is my Idea:

Sprint reviews, everyone is invited. It is where the devs show off their work to anyone involved. You have a very good reason to go you are involved very directly. Go to these, see what has been written, it should also tell you what is inline for next sprint.

Participants in the sprint review typically include the product owner, the Scrum team, the ScrumMaster, management, customers and developers from other projects.

https://www.mountaingoatsoftware.com/agile/scrum/meetings/sprint-review-meeting I would classify you as a dev from another team, or maybe even a customer.

If you see something important that looks good for automated testing arrange to speak to the team leader after the review to discuss it further. I would write a detailed test script and pass it to manual testing for review "can you just check the expected results please?"

I am not sure how senior you are or how much autonomy you have so you may be able to just say you will be doing this and check the manual testers have time.

These test specs are really really useful when an error is thrown in that script in 2 or more years time and nobody can remember anything about it.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .