New to the field of QA, I've been asked to do SQA for a project that I'm unfamiliar with and that is close to completion. An example of a specific functional task to be tested looks like the following:

51: Rename Excluded Words at the Topic and Subtopic levels to be Not in Topic and Not in SubTopic

I could see how if I was the developer who built the project or had I been roped in on this since the beginning, then it'd be fairly obvious to "Click here" and then "Click this button in the drop down" followed by ... etc, etc. Either because I developed the project or because I've tested the project as it's being built from the ground up (and thus I'd know it inside and out). But because I'm new to this project and it's relatively large, I don't know the steps required to actually get to the part where I "rename excluded words". Hell, maybe it's actually broken and that's why I couldn't find it.

The above is just an actual example, but my goal here is to gain some insight that I can apply to my practice in general.

If the SQA is new on a project already in development, should the developer provide steps needed to perform the function to be tested?

Not necessary every step for every test (like creating a new user) but strictly for more hidden or complicated features.

  • 1
    You being new, and not used to 'the flow' is something I'd consider a good thing if I had you on my team. Your job is not to verify that things work when you do exactly what the programmer intended. Do things a user might, then do something a blind person would do - then try some exploits or hacks (if you're in to that). I would say you should get some guidance, and somehow you should document things. My 0b10 – AlexanderBrevig Aug 30 '16 at 3:56
  • "Technically" QA is supposed to be an independent department within an organization. As such, the QA department is responsible for setting its standards. Thus, the level of test detail should be a discussion held among the QA team to get the QA team in agreement as to minimally acceptable standards. Of course once QA decides their preferences then it is best to haggle with engineering to finalize on something everyone can be happy with rather than dictate (although that is sometimes necessary). IMO, I think detailed steps saves time for everybody even if it takes a little more time initially. – Dunk Aug 31 '16 at 16:04
  • I just went and confirmed that there is a Software Quality and Assurance community on Stack Exchange. Perhaps this question should be moved there? – Dunk Aug 31 '16 at 16:07

If you don't know an application or a feature in an application well enough to basically use it, you need to learn this first, that is an obvious prerequisite of any testing. There are two ways to do this: RTFM, or let someone explain it to you (both ways not mutual exclusive). The person who explains it to you might be an experienced user, a business analyst or product owner who knows the requirements well, someone else from the development team or from the support team, whoever can do this best in your specific case, in your organization.

It might be a good idea not to ask the one dev who developed the feature only, since he might have misunderstood some details of the requirements, and job of QA is not only to check if the program does "exactly what the programmer intended", but also what the user expects or the manual says, which is not always the same. So if you have the possibility to double check the original requirements documents or manuals, or ask a user about his expectations, make use of it.

To your question "shall the dev provide the steps": assumed the test procedure is complex enough it needs some written steps to reproduce it, you will probably need a test plan. Whose task it is to write such a plan may also be specific to the organization, but it is not untypical the QA people have this responsibility by themselves. Maybe someone else just need to explain the steps to you, and you can write them down for you and your colleagues, if noone else did before? So this also boils down to: "you have to find out what works best for you and your organization", similar as above.

  • "assumed the test procedure is so complex it needs some written steps to reproduce it, that might be a sign of a badly written or missing manual". You are "assuming" a certain level of background knowledge of the person running the test to make that claim. Running the test procedures is a good way to learn a new system and having the steps explicitly called out which map to the requirements being tested is certainly preferable than having every new person go around asking the same questions "how do I do this?". IME, reading a manual only helps once you are somewhat familiar with an application – Dunk Aug 30 '16 at 17:42
  • @Dunk: you seem to agree perfectly to me that this might be is a sign of a missing or badly written technical manual for the tester. And if that is the case, my suggestion is the tester should work together with the rest of the team to fill that gap. So where is your problem? – Doc Brown Aug 30 '16 at 18:03
  • Sorry, I went off on a tangent to my "so complex" disagreement. Test procedures test specific functionality in order to ensure specific results are achieved. Without specifying detailed steps, how would you ensure the correct results are achieved? How would you ensure the various edge cases are tested? How would you ensure error test cases are covered? I wouldn't expect a manual to provide this kind of information. I also wouldn't expect someone new to a project to be able to figure it out in a reasonable time frame. The easiest solution is to simply include the details in the test procedure. – Dunk Aug 31 '16 at 15:23
  • @Dunk: ok, I agree, for systematic QA, especially for manual testing, this should be part of a test plan. Edited my answer accordingly. – Doc Brown Aug 31 '16 at 16:25

In my sense, the best way to get an application tested, is to put someone who doesn't know the project at all; especially how it works. Here some points for why:

  • If the project has a user guide/manual, just following that in order to help you to do all of the tasks asked. This will show that the manual is/n't well written and usable for a lambda user.
  • If there is no guide or manual and you succeed to do your tests, that shows that the project is well designed and even someone not directly related to it (i.e every future user) will be able to use this feature without too much explanation.
  • If there is no guide or manual and you don't see how to do your tests, that will help the developer to see which part of the project design to work to make it easier for the user to use this feature, and if no changes are planned, that will indicate which part of the project must be documented in the manual.

The thing is that you will be new to the project for only a small amount of time. You will be able to better see the eventual flaws in the project during this period so use this advantage to point out every step that may look unclear to you as a new user that your other colleagues may not see because they are used to it.

No. Dev knows of the bussiness in a different way than the analist or the QA. I would suggest you refer to another college of yours. If you are alone testing the application, I would prefer you talk with an SA or BA (which may understand the system more from the perspective of the user), or even the user itself.

A Developer may simplify things for you, mainly because they know the inside of the app. QA is supposed to go over (almost) all possible flows.

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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