What is PreQA or Dev testing in Agile
In the following article we are going learn a small area of
-what is Pre-QA(a kind of Dev Testing)?
-How to do Pre-QA?( a brief scenario description)
-What are the merits and demerits of pre-qa?
- Pre-QA , Why and when?
What is Pre QA?
Pre QA by word definition, some processes or tasks done before real QA. In another word, when we do testing beside developer before the code committed to main trunk , that is called pre-qa. After Pre-qa pass , the work will be ready to QA. We can say, it’s more like development sand box testing
The main goal is for pre-QA to get issue(ticket) ready for full QA .
Now, let’s go detail on How to do Pre –QA.
1. Pre -QA is always a On Developer’s call( developer’s demand). In many team it is must do, but better On Developer’s call as it will instantly find the bugs and developer need to have the mindset.
2.Pre -QA is always done before code committed to main trunk(not even local committee)
3.Pre -QA is always done on developer’s PC side by side(like pair programming, where QA will be the driver & the may be the developer himself)
4.On a Pre-QA, a SQA Role is like as Driver (Ref- pair programming).
The steps a tester should do.
a.Read the full ticket before coming to developer’s environment
b.Spatially read the comments & define the scopes
c.Keep the major test areas/paths before coming
d.Double check the ticket on satisfying the FRS/SRS before coming
e.With the developer, first listen the full ticket/job about from developer
f.Then discuses with reading the ticket & define the scope for testing
g.Define the paths to test
h.Do the tests with keep eyes open to find bugs & behavior of the product
i.On fail, no argument, Just make a list of failed cases and give to developer
j.Keep a list of possible fail areas for further necessary (from observation during Pre-QA) and if possible comment / discuses with QA team and have listed for checked items before release or integration.
k.When developer will come up with solved list (provided in pre-qa), do the test paths again.
l.Some case will verify, some cases won’t and some new faults will rise up.
m.Now, Notify to QA Lead and project manager or product manager.
n.In here, the scope will be specified. Some will go to known bug, some will move to next sprint or rescheduled and some will go to QA box.
o.Now, QA will take a build, verify the solved & unsolved issues, and post the unsolved issues with the reference(build no) in the bug tracker as well as Agile board.
5.On a Pre-QA, a Developer role is as Navigator
a.Open the ticket read with the SQA
b.He should discuses about scope & effect of the code that he has done.
c.He might show the changes in the modules related to topic( detail understanding for code effects)
d.He can show the design diagrams to SQA
e.If , Frontend work involved, Mock-Ups should be shown to verify.
6.Time limit
a.10 min default
b.Best practice 5 min
c.Maximum 15 min on EPIC ticket
What are the merits & demerits of the process?
Merits:
1.Faster delivery tickets(quick builds & Rapid development)
2.Stop wasting time on reporting/reading/communicating with bugs(less posted bugs)
3.Discuses more on issues for better understanding among the team(developers or QA members)
4.There will be no unknown areas to anyone with More knowledge about business requirement
5.Team became more careful on product ( I have seen many developers showing bugs while doing pre QA)
6.Product become more stable before release and the risk factors become less.
Demerits:
1.Developer/QA members may react on the Pre-QA. A negotiation and professional attitude may resolve the issue( a senior may involve initially to clarify the necessity among the team)
2.It does not follow the traditional testing process.
3.Some issue may be easily miss-judge or overlooked or forgotten if notes are not carefully taken care of.
4.Senior QA members preferable for initial Pre-QA process, so hard for newly QA member to adopt the process and attitude.
5.Large number of team(200+) may face some difficulty to follow all the procedure if they are not properly grouped.
Pre-QA , Why & when?
Well, if you look at the above article, it’s very clear that pre-qa eliminates un necessary documentation, bug reporting, bug investigation time(both qa/developer). So, when we need a rapid development, when there is small release time, which will be perfect situation for Pre-QA practices. Pre-QA not only boosts up the development process, but also increases the interpersonal relationships among team. A team of 20-60 members , can easily follow the pre-qa process along with agile board. If the team is in large scale, they can also follow this by grouping them into small team(scope wise).
And, for following best practices of agile, pre-qa is unavoidable to ensure quality products.
-what is Pre-QA(a kind of Dev Testing)?
-How to do Pre-QA?( a brief scenario description)
-What are the merits and demerits of pre-qa?
- Pre-QA , Why and when?
What is Pre QA?
Pre QA by word definition, some processes or tasks done before real QA. In another word, when we do testing beside developer before the code committed to main trunk , that is called pre-qa. After Pre-qa pass , the work will be ready to QA. We can say, it’s more like development sand box testing
The main goal is for pre-QA to get issue(ticket) ready for full QA .
Now, let’s go detail on How to do Pre –QA.
1. Pre -QA is always a On Developer’s call( developer’s demand). In many team it is must do, but better On Developer’s call as it will instantly find the bugs and developer need to have the mindset.
2.Pre -QA is always done before code committed to main trunk(not even local committee)
3.Pre -QA is always done on developer’s PC side by side(like pair programming, where QA will be the driver & the may be the developer himself)
4.On a Pre-QA, a SQA Role is like as Driver (Ref- pair programming).
The steps a tester should do.
a.Read the full ticket before coming to developer’s environment
b.Spatially read the comments & define the scopes
c.Keep the major test areas/paths before coming
d.Double check the ticket on satisfying the FRS/SRS before coming
e.With the developer, first listen the full ticket/job about from developer
f.Then discuses with reading the ticket & define the scope for testing
g.Define the paths to test
h.Do the tests with keep eyes open to find bugs & behavior of the product
i.On fail, no argument, Just make a list of failed cases and give to developer
j.Keep a list of possible fail areas for further necessary (from observation during Pre-QA) and if possible comment / discuses with QA team and have listed for checked items before release or integration.
k.When developer will come up with solved list (provided in pre-qa), do the test paths again.
l.Some case will verify, some cases won’t and some new faults will rise up.
m.Now, Notify to QA Lead and project manager or product manager.
n.In here, the scope will be specified. Some will go to known bug, some will move to next sprint or rescheduled and some will go to QA box.
o.Now, QA will take a build, verify the solved & unsolved issues, and post the unsolved issues with the reference(build no) in the bug tracker as well as Agile board.
5.On a Pre-QA, a Developer role is as Navigator
a.Open the ticket read with the SQA
b.He should discuses about scope & effect of the code that he has done.
c.He might show the changes in the modules related to topic( detail understanding for code effects)
d.He can show the design diagrams to SQA
e.If , Frontend work involved, Mock-Ups should be shown to verify.
6.Time limit
a.10 min default
b.Best practice 5 min
c.Maximum 15 min on EPIC ticket
What are the merits & demerits of the process?
Merits:
1.Faster delivery tickets(quick builds & Rapid development)
2.Stop wasting time on reporting/reading/communicating with bugs(less posted bugs)
3.Discuses more on issues for better understanding among the team(developers or QA members)
4.There will be no unknown areas to anyone with More knowledge about business requirement
5.Team became more careful on product ( I have seen many developers showing bugs while doing pre QA)
6.Product become more stable before release and the risk factors become less.
Demerits:
1.Developer/QA members may react on the Pre-QA. A negotiation and professional attitude may resolve the issue( a senior may involve initially to clarify the necessity among the team)
2.It does not follow the traditional testing process.
3.Some issue may be easily miss-judge or overlooked or forgotten if notes are not carefully taken care of.
4.Senior QA members preferable for initial Pre-QA process, so hard for newly QA member to adopt the process and attitude.
5.Large number of team(200+) may face some difficulty to follow all the procedure if they are not properly grouped.
Pre-QA , Why & when?
Well, if you look at the above article, it’s very clear that pre-qa eliminates un necessary documentation, bug reporting, bug investigation time(both qa/developer). So, when we need a rapid development, when there is small release time, which will be perfect situation for Pre-QA practices. Pre-QA not only boosts up the development process, but also increases the interpersonal relationships among team. A team of 20-60 members , can easily follow the pre-qa process along with agile board. If the team is in large scale, they can also follow this by grouping them into small team(scope wise).
And, for following best practices of agile, pre-qa is unavoidable to ensure quality products.