Guys,
I have a practical situation to handle.
The build release cycle for the client in my company is on daily basis.
So QA receives build at around 4 or 5 pm and would have to deliver the build by 7 or 8 pm. In such a short timeline, the QA is not able test the whole application in the same day. He only tests the defects that have been fixed and changes that have been made with a few tests on impact of the fixes too. We do a complete round of testing the next day morning, but until then the client who's located in US does a full round of test and gives us defects in the morning.
Now, if we think we could insist on Dev giving the build earlier than 4-5 pm, thats not quite possible becoz we have a daily call at around 12-2 pm with the client who prioritizes the issues to be fixed for the day. For the plight of Dev guys having 3-4 hours of development time, we can't even reduce their timelines. And as the client is so demanding for the defects fixes and CRs for the day we can't even reduce the no. of defects handled per day.
To add up to our complexities, the tester and developers working on this project are both inexperienced.
I'm just wondering what would be win-win solution for all (Dev, QA and Client)? I'm in a deadlock situation, pl. bail me out! ;)
Subscribe to:
Post Comments (Atom)
Posts
Meeting at 12-2 pm
ReplyDeleteDev fix the defect 2-4 pm
QA gets build at 4-5 pm
Sign off 7-8 pm
Seeing above I remember few of our Playtech days :)
This is very critical situation(I m not surprised), BUT It can be handled reasonably If you plan well and Marshal your resources
1. Stop thinking that you are Inexperienced, accept the fact that there will be issues in this kind of scenario but take this as a challenge to deliver.
Coming to the problem:
I assume you(QA guys) are also part of meeting with client along with dev and manager
I again assume that you(Manager) agree only to content that is feasible to fix and test that same day
1. After meeting the Info from developer about the nature of fix or request(easy, medium, complex)
2. While the dev is working to fix the defects, you can start
-Writing down scenarios Including scenarios for Impacted areas
-Gather test data
-Any other tools required for testing
3. It should be agreed with the developer that he will do unit testing before giving the build, his estimates must incluede this, so that risk is reduced.
4. Once you get the build you can start execution
5. Most Important thing is maintaining daily report(It can be a normal one not something fancy, purpose is to understand info clearly) for activities you are doing because as you said you get a daily build, you can measure the quality of your testing based on that.
6. Finally when you sign off send a report along with a risk list so that client is aware of what to expect
For these kind of situations you need to be alert, sharp and Innovative to get good results, overtime you will realize experience doesn't matter If you have ZEAL & PASSION for the skill :)
If your company can afford some automation tool, it can support your effort but It cannot replace manual testing.
I hope this helps
I would do the following:
ReplyDelete1.Come up with a Risk document clearly stating the Risk & it's impact.
2.Would talk to the development team & ask for the impacted areas.
3.If possible I would prefer the dev team to perform unit testing & publish the results.
4.Always urge the development team to issue a very short release notes i.e. list of known issues..so you save time not logging them.
5.I would recommend you to keep track of the builds & features you tested in a seperate document.Re-visit it from time to time & re-test the application in you leisure time.
6.Start using automated tools such as "Session Tester" to log your work.
7.Try new ideas such as Pair testing when you have enough time for testing.
Ravindra.
Great inputs guys,
ReplyDeleteI agree to both of your every point, and all your points very much applicable in most such situations, except for Automating the tests in this project. As this is an mobile (iPhone to be more specific) based project automation is ruled out.
But I'll definitely try to implement the new ideas that you guys have generated in me, into practice.
Thanks a lot, Shiv and Ravindra!
--Madhav
I agree with Ravindra said... We should have risks and also assumptions document prepared and signed by everyone which will save us and let them know the situation of our testing. And any slippages will definitely cannot create arguments.
ReplyDelete