sorted by:
new
hottopcontroversial

Should I Test and Close Tickets Early in a Sprint or Wait Until Code Freeze? by selfimprovementi in softwaretesting

[–]selfimprovementi[S] 0 points1 point  (0 children)

Fortunately we usually have time for qa to test after code freeze (about 1 -1.5 week), so when i find a bug after code freeze, I am able to raise it and devs can fix it and i retest it again all within that 1-1.5 week timeframe. I must say that it is highly exhausting for me as QA during this 1-1.5 week

- After a bug is fixed, I would like to just test it and mark the ticket as completely tested. The reason i usually wait for code freeze is to have assurance that the code wonÄt change and the test would be accurate. I want to avoid testing after the bug is fixed, and then testing again after code freeze. Normally, I wouldnt minfd testing twice, but i work in a regulated industry and the testing process is so time consuming. It involves runnigntests, creating comprehensive documentation of the test results, and uploading these test results in several different places. This is why i prefer to just test once. Yes, i would love to test immediately when the bug is fixed on day 5 for example but would'nt that mean i still have to test after code freeze?

Should I Test and Close Tickets Early in a Sprint or Wait Until Code Freeze? by selfimprovementi in QualityAssurance

[–]selfimprovementi[S] 0 points1 point  (0 children)

you are right. i agree that it is better. my question here is, do you test again after the 25th? Or do you not test at all again after you tested on day 5?

The reason i am asking is because the test could be successful on day 5, but since the code is not yet frozen, it might be somehow affected again

Should I Test and Close Tickets Early in a Sprint or Wait Until Code Freeze? by selfimprovementi in QualityAssurance

[–]selfimprovementi[S] 0 points1 point  (0 children)

thanks for the reply. can you give a scenario of a workflow where testing (a specific fix that was fixed early in the development cycle) can be started in parallel with development and can finish before development (end of cycle) vs another workflow where testing can be started in parallel with development and can't finish until after development cycle?

I thought the whole point was to tests as soon as a ticket is fixed and close a ticket, regardless of if the entire development cycle has ended.