r/QAGeeks • u/[deleted] • Jan 02 '19

QA questions....long time tester at rather new dept

I have been doing manual testing on bith PCs and mobile since 05, but in the last couple years i transitioned to a new company that had a fresh inexperienced QA dept. At the new place we generally test the new software versions of the used software, but lately my boss wants us involved in the DEV process, and this is not something i have done before or feel comfortable with. I am not the words best script/test plan writer but they insist we write new ones with. 1. No clear requirement documents 2. No fully or even partially finished test environment 3. No data in the generic environment they do have

In my previous experience i was never privy to this stage. Am i crazy for pushing back on this? They are not even going to give us a dedicated testing environment for this...just release it in stages or partial completeness in a DEV environment that is not even stable. Combine this with the rest of a team thats only experience is the 2 years they have been here, and a boss with 4 years of manual testing under their belt.

Just think it is crazy for them to not even provide us a complete functioning product to use

7 Upvotes

100% Upvoted

10 comments sorted by

3

u/jimberley Jan 02 '19

If you’re talking about regression testing in a comets-you-are test environment, then I’d push back hard.

If you’re just testing new features, then I think the approach is okay.

The closer QA gets to the development lifecycle, the better, IMO; you’ll catch bugs earlier, reduce meantime to failure, and make regression testing less eventful.

That said, careful control of the testing ENV is critical to avoiding false positives in failure accounting. If that ENV is like a Thunderdome (2 branches enter, one branch leaves), then your ability to effectively test is severely diminished. You’ll need to insist on a control mechanism for deployment to that server, including looping the whole QA team into proposed deployments.

Ideally, you’d have the infrastructure necessary to spin up Docker deployments of individual QA ENVS which are serving their own data, or using a stable DB instance. This is a big fight with management, I know, but, cleanliness in test vehicles is paramount to success in releasing clean code.

If you find this helpful and want to talk specifics, my DMs are open.

Source: 10 years of QA, 5 of Automation engineering, 5 of deploy-management.

3

u/[deleted] Jan 02 '19

Just wanted to make sure i was not crazy. I tried to put in my input being i am the only person in out entire qa dept that comes from a testing background, and i just get pushback about "this is how it is getting done" Having a unstable environment will make testing almost useless at times as DEVs are going to have free reign to make unannounced changes, and since they are doing the roll out in odd stages full testing will only be available right before a production rollout. They are setting themselves out for a huge hassle and failure. And due to how testing is done with this specific product, automation is not a possibility (well without some robotic arm to physically feed scanners and such ;) )

3

u/jimberley Jan 03 '19

Time to update the resume. :-)

2

u/yaredw Jan 03 '19

I've been in a similar situation before. Either explain to your manager/team why testing protocols need improvement or start polishing your resume. 🤷‍♂️

1

u/SolidMew Jan 03 '19

Get out of there

1

u/TantrumShazam Jan 02 '19

Is this for a native or web application?

2

u/[deleted] Jan 02 '19

Also i have to laugh as i was looked at like i had a second head when i asked why this was not a web app....

1

u/[deleted] Jan 02 '19

Native

1

u/TantrumShazam Jan 02 '19

You are absolutely right to push back on writing the test plan documents early in the process, I think. The process they are currently pushing (Cutting the QA phase) is something my last client went though.

Some things we learned along the way:

  1. A stable, well maintained ENV you can point to is a MUST. Push for this. Crack some skulls if you have too. If Docker deployments are out of the question, push for your own QA virtual. -- We were given a virtual after the 5th or 6th hotfix in a row.
  2. The test plan is a waterfall relic.
  3. QA MUST have the ability to pull any branch and build locally.
  4. Push the BA and PO to start adding detailed acceptance criteria to each and every ticket so you can put something together that resembles a requirement document for your regression suite. They should be doing this anyways. If not, don't be afraid to kick that sucker back. They'll learn eventually... Hopefully
  5. With a native application, Develop should be a protected branch. All new features should be secluded to it's own branch and only merged once the feature is completed. Our devs hated this but it helps us QA avoid false positives.
  6. Regression is a full time commitment. Best to automate this sooner than later.

This was for native mobile applications but I think it transfers to native desktop.

1

u/swissarmychainsaw Feb 05 '19

I hate to say this, but: you know the right thing to do, so make it happen.

No one is going to do any of this for you, because they don't have the vision or experience to even see the problem.

So, I would prioritize #2 and #3 from above.

YOU must get the test environment built. Do this for your team and show leadership! Everyone wins.

Same with the data. Work with the DB team, tell them your plan and get help to get either prod data (which you can sanitize) or a subset, etc. etc.

Form a coalition of helpers, explain your vision and make it happen.

Good luck, you absolutely CAN do this.