2

I have two legacy applications with huge source code base which should get integrated into one application. As my knowledge of the domain of the applications is quite limited and there is no testing documentation (only exploratory testing was done till now) , I want to prepare a set of test cases to cover existing application functionality. Afterwards I want to use these test sets after the merge of applications to assure that from functional point of view new app works in the same way as old apps and the changes in code didn't cause any regression.

I researched on this topic and found some methodologies which might be usedful:

  • ACC (attributes - components - capabilities) - this is rather manual process and depends strongly on the experience of a test engineer (https://code.google.com/p/test-analytics/wiki/AccExplained)

  • MBT (Model-Based Testing) - test cases are automatically generated using specialized tool, test cases quality depends on the quality of a model i.e. the things we didn't model won't get tested

  • BDT (Behavior Driven Testing) - test cases will be derived from user story acceptance criteria, again it's a manual process

What would be the best methodology to use in my case ?

Improve this question
7
  • This kind of question ("describe your favorite somethings") is imho not a good fit. Maybe it should be split or changed to be less open. – prockel Aug 14 '14 at 10:39
  • @prockel OK, I rephrased last sentence trying to be more precise. – tommyk Aug 14 '14 at 10:59
  • 1
    Even with the change, it's still very opinion-based - could you perhaps consider the slightly different question of when it's better to use one type of test case generation over another? – Kate Paulk♦ Aug 14 '14 at 11:39
  • @KatePaulk I know this is kind of a survey-like question but this exactly is what I need. I would like to get to know other methods I don't know yet ... – tommyk Aug 14 '14 at 13:20
  • 2
    Hi TommyK, I don't want to be 'that guy'. It's obvious you have a need and want it resolved. But here's what I would say is the underlying problem: we don't know what you're trying to solve. You're asking us for what we do. You should be approaching it for what you really need - what work problem are you trying to solve? That will make it more objective, and you will get the information you really need! – corsiKa♦ Aug 14 '14 at 15:04
2

Sure you could use any of these or others out there or do your own. To start I think you should ask a few questions and get those answers.

  1. What test output is needed? This could be...just test it and call it good or it could be some kind of report which would indicate the test needs to produce results that match that criteria.
  2. How can I functionally breakdown the applications into something tangible? This could be workflows/use cases/requirements/test objectives/code breakdown etc...
  3. What is the main point of each functionality? This usually involves the market of what the product is designed for in the first place. This is your "user focus" question to make sure your testing is lining up with the users expectations.
  4. Is there any process that must be adhered to? Based on your feedback of your applications so far I think this answer is no, but it's always good to make sure your testing lines up with a standard delivery process so that you can schedule proper testing along side development. I'm sure someone at some point in the life cycle development has release criteria.

After you have all of that information you can see what "artifacts" will be most important for you. By "artifacts" I mean anything that stays around to help in the future. So Test Cases(manual/automated), Requirements, Use Cases, Work Flows, Bug report summaries, functional breakdowns, etc...

Your chosen method will then be easier to choose once you know what you need to end up with. Then you can start by creating those artifacts for the existing applications. Then merge those artifacts together for the future application. Automated tests and manual tests would be able to be extrapolated from the information at this point.

Improve this answer
0

MBT would not work. Reason: You claim that you domain knowledge is quite limited. Its hard to model something that you do not understand.

BDT may work but will not be complete. Reason: With limited knowledge of the domain means you might not be able to identify all users & business processed. No testing documentation means you do do not have a way of ensuring coverage.

ACC - not sure i understand how it is done.

What would work is do Parallel tests. 1. Test system 1 - document all testable functions - come out with test cases and test data 2. Test system 2 - document all testable functions - come out with test cases and test data

when you have the new combined system execute both sets of test cases and ensure you have the same functional output. You can use these test cases as building blocks and build test cases for the new combined system.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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