Testertools Forum

1. ntminos
   Member

   Reputation:57

    

   What are the best tools and technicians to start a SQA process in a company that has all of their software already developed but because they never Q Aed them (the developers just tested their modules) it's actually problematic at some modules? They're not concerning about budget, and there would be only me and myself on the QA team, at least for a while! They have very little documentation for their early code and quite a bit for their recent code. They also have data models. What tools actually rocks on SQA? Help!

   Posted 1 year ago #

2. Pamela
   Member

   Reputation:297

    

   Since you are the only tester, I would consider looking getting involved early, using some Agile methods and concentrating your tests on high risk areas.

   By getting involved early, you should stop bugs early. If they are stopped before they are coded this will save you time during test execution.

   One useful Agile method might be eXtreme Programming (XP). With this approach, each unit would be tested as it is developed and quality would increase with the use of pairs programming. There are other methods as well - try to find the one that fits with your shop.

   Then, you could concentrate on the high risk areas of the application, once development hands it off.

   - http://testing.com/agile/agile-testing-essay.html
   - http://www.satisfice.com/articles/hrbt.pdf

   Posted 1 year ago #

3. ntminos
   Member

   Reputation:57

    

   But the problem is that the application is already developed and the old piece of it is buggy and has few documentation - this is the risky part, right? I was thinking about analyzing the whole business and creating a model on Rational Rose and from that I'll have all necessary testcases, data models, etc... what do you think? They have data models for the new development. The app is written in C++.

   Posted 1 year ago #

4. Cyril
   Member

   Reputation:372

    

   Now that the application is ready, the best way to follow is Divide and Rule. Break the application in small modules (either based on functionality or flow). Take up each module, understand it completely either from the dev. team or from Bus. Analyst. Write the test cases based on the understanding and test it. Since the product is ready, some developers could be relatively free. Get them to write and bring the documentation in place.

   Posted 1 year ago #

RSS feed for this topic

Reply

You must log in to post.