Hello, all. I’m wondering if anyone has experience with documentation and knowledge transferring, namely from developers to QA.
One thing that slows down my QA team is when we don’t know the coded logic behind something. Sure, we may have a test case that says to make sure some amount gets populated, but we may not know what the calculation is that results in that amount. A script may reference an auto-populated date, but how that date is determined?..beats us! Going forward we include calculations and logic like that in the test cases, or somewhere where it is visible to us. However, we have years’ worth of code and logic that have never been documented.
It would help us test better if we knew what the logic in the code is, but we don’t have access to the developer’s .NET code (separation of duties). Some of us don’t even have Visual Studio. QA would need to reach out to a developer and have them show and explain the code to us, which we don’t always have time for.
Does anyone have any tips, tools or process recommendations that makes this type of knowledge transfer easier? I’m afraid this will ultimately be a painfully manual process, to build up this type of documentation, but any suggestions would be super appreciated!
It’s always a pain to test black box and to not know what happens. I would say it should be in the analysis but yea you mentioned no docs. If they want you to do your job, tell them you need access to it (even if it’s only read-access) or tell them to explain it or you can’t do your job properly.
If all hope is lost there… you can always try to reverse engineer the code
Why aren’t you allowed to access the code?? I’d start there.
Because building your own “test logic” on top of the code logic based on black box data/requirements, that’s meta and it’s bound to be error prone.
Can you push to get access to the course repos? At one of my past jobs I was working on a legacy project, which was very poorly documented, but fortunately we had access to all of the source code. I used to just follow what code what saying to figure out what’s going on. Combined with DB access I was able to make sense of the legacy madness - most of the time.
@maaike.brinkhof
Short answer is due to audit. One person/role can’t have access to all environments - Dev, QA, UAT, Prod. The idea is to prevent something malicious from happening, for example, a developer wouldn’t be able to add malicious code and deploy it to Prod themselves. The build would have to go through proper review and approval channels first.
Developers can show QA the code as long as the dev is in the driver seat, but QA can’t access or make changes to it. Right now, even if QA could access the code, many of us don’t know how to read it (it was never required before). However, maybe that is something I can talk to my company about - if QA can get read-only access, and we learn the basics, then we can at least try to be more independent and not need to rely on the developers’ time as much, unless absolutely necessary.
@kristof
Ha! Luckily we have a great team here, and the devs would be more than willing to help. It’s just an inefficient use of their time (but then again, it’s not efficient for QA to be left wondering if they are even testing thoroughly). This is one of those things we may just need to bite the bullet on, and insist that people dedicate X number of hours a week to it.
@mirza
Thank you for the suggestion, that’s a great idea. I’m going to ask leadership at our next meeting if this is an option. Any way we can have QA be less reliant on developers to find this information the better for everyone. Thank goodness we at least have access to the database, so we can find our own data to test with.
Luckily we have a great team here, and the devs would be more than willing to help. It’s just an inefficient use of their time (but then again, it’s not efficient for QA to be left wondering if they are even testing thoroughly). This is one of those things we may just need to bite the bullet on, and insist that people dedicate X number of hours a week to it.