2

I work as a Developer on a product that is implanted in the client's website.

In our development process, we develop the application, deploy to our Development environment, do testing to see if everything is working, deploy to the next environment, do our tests again, then call the client so the can test it on their test page, alongside with their QA people, then if everything is ok, we can deploy it to Production.

The thing is, some times the client QA is flooded with other demands so testing our deploys can be thrown into the backlog for a while and so the Releases end up taking quite a time to get ready, with all the finding and fixing errors.

We already tried to ask for access to the client's test page, but because of security reasons, firewall and others they are not able to allow us.

I want to know if there is anything that can be done to help speed up or improve the client's team QA process, so thinks would move faster? Maybe sent them the Unit tests list or have an Integration test process on our side.

We never had a QA process so for now I am having to wear that hat for now.

Note: I have almost no knowledge of QA/Testing, aside for some brief reading I've done on my own and Unit Testing, so any tip is helpful.

  • 1
    What problem you are trying to solve? Does client demand faster deployment? If not, maybe focus your energy on test automation, so you can (1) test faster, and (2) run your test on client's system without having the access. – Peter M. Mar 6 '18 at 14:01
0

As you suggested, Automation can be a good tool for speeding up, but it will only have effects if the second tip is strongly implemented (I'll get there in a moment).

Firstly, however, I suppose the testing performed by the client team is exploratory testing, performed manually - i.e., you need to automated that kind of testing. Keeping the test pyramid is important overall, but if you don't have a good coverage of functional testing, probably the effort of the client team will be the same. However (again), even if you have good user interaction tests, you will need to communicate properly to the client testing team (not their manager) what is automated. BDD frameworks can help you with that, by providing an english-description of the steps of your tests. (This article can be helpful as well).

The second tip is that trust and communication are essential. You guys and the client team need to know what each other are doing and trusting that the work is done properly. This can be reflecting in:

1 - Trusting (by their side) that the aforementioned Automation test suite really performs the checks it propose;

2 - Highly communication of what are the risks that your previous tests (auto and manual) could not be properly investigated. I.e., which areas really need to be deeply explored by the client team. These grey areas usually exists because differences in environments or production data size or particular relationships amongst entities. With time, you should be working on mitigating these differences, but for starters, the client team should be focused on these areas, not on stable or deeply tested areas. It will both improve time to production and make their work more precise, because they will have less things to focus.

0

This is largely a transparency issue and ultimately a trust/confidence issue. Exposing your automation to the client QA and Dev teams to synch on coverage such that their confidence is raised to the point where they can either reduce their manual testing efforts and alleviate the bottleneck or you can plug coverage gaps such that the same can happen. Subsequent reports/dashboards would help.

Some clients simply won't do anything else though, at which point it is no longer your problem once the bottleneck is identified and communicated up the chain.

0

If I were in your position, I would use admin toggles to keep new features turned off until they indicate they are ready to test on their test environments. Then they can turn those toggles on in their test environments, and when they are happy with the results, turn the toggles on in their production. Meanwhile you guys can happily code and deploy away on whatever's behind the next toggle.

Once everyone's happy and the toggle is permanently 'on' in production, you can just remove the toggle.

This can lead to more testing since you have to test that old features are still working with new features, but if your client is really not prioritizing testing your work, it's probably worth it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.