Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 214
  • Last Modified:

Getting up to speed on QA

Hello.

My company is in the process of developing a major low-level upgrade of our application. It's a
a WATCOM C application, and we are porting
it from 16-bit DOS to 32-bit NT.  it is NOT
a windows application:  it runs from the command prompt.  

Most of the development is being done offsite.

Early testing has convinced me that we have
an exhaustive QA effort ahead of us, both in
identifying what exactly needs to be tested, and
actually doing the testing.

Can anyone offer any suggestions as to how
to approach this task?  Either some actual
pointers, or perhaps suggesting a book (for
us to learn) or a tool (that might aid our
efforts)?

Many thanks!
stevefromc
0
Stephen Kairys
Asked:
Stephen Kairys
  • 2
  • 2
1 Solution
 
Arthur_WoodCommented:
first question, do you have an EXHAUSTIVE set of FORMAL requirements that the developers are programming to?

AW
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Not exhaustive nor paticularly formal. They know that the general concepts (dealing with 16/32 bit integer issues, screen handling issues, etc) but I do not believe a detailed, formal spec exists.
Thanks
0
 
Arthur_WoodCommented:
without EXHAUSTIVE requiremetns, how can you know whether the developers did what they were 'supposed' to do, and thus how can you test if what they did was 'correct'?  

The problems will come in where what you thought you asked them to do, and what they understood you asked them to do are different.

It's as case of "I know you heard what I said, but what you understood is not what I meant" - and they programmed based on what they understood, and not necessarily weaht you said.  That is the purpose of a FORMAL requirements documant, that both parties agree to - so that what is required in written done, in black and white.  Then  you can test to make sure that what the programmers wrote does what the requirements said was supposed to be done.  As it stands now, you have no way on knowing what they wrote, much less if what they wrote is 'correct'.

About all you can do now is to start writing up some test cases as you can, to test what YOU think the programm is supposed to do.  Think of how the typical user will make use of the program (so-called USE CASES), and then write down as exhaustive a set of test cases as you can think of, and then ask the users if what you have written down is correct, and ask them to add any additional cases that you did not think of.  Even then, without the  requirements, you may not be able to test everything that the programmers did, becuase you have no way of knowing what they actually DID DO.

AW
0
 
Stephen KairysTechnical Writer - ConsultantAuthor Commented:
Thanks. I think that writing up the test cases, and asking for input from others (in
this case it might be other people in my programming/tech support departments).

Your ponts are very valid and personally I am always in favor of detailed functional specs.

These methods aside, do you (or anyone else out there) know of any good QA books
that might help?

Thanks again
stevefromc
0

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now