3

I'm working in a very huge PHP project, but for many reasons the whole project was never tested until now. FYI, the project consists in a lightweight enterprise PHP framework based on Laravel.

My task is create a test plan for the project and I thinking about the best approach for this kind of project.

My first option is start with unit tests using PHPUnit, but I don't know if I can ensure the test of all important methods, 'cause the methods were created without a planned test.

For sure, I'll do some manual test, but also I don't know any good technique to do it in large projects without a previous test plan.

So my question is: Which is the best approach to test this type of software? Are there some specific technique for late tests?

Improve this question
3
  • So it's "late". How much time is available for testing? How many people can participate? (You'll get a different answer if you say "this must ship tomorrow and I'm the only tester" versus "It ships in mid-2016 and we can hire up to 10 professional testers")
    – Joe Strazzere
    Nov 11, 2015 at 12:35
  • What is the level of risk here if it's insufficiently tested and hence buggy? (You'll get a different answer if it's an internal application that will quickly go through several versions, versus it's a SaaS application that is the lifeblood of all of your safety-critical customers)
    – Joe Strazzere
    Nov 11, 2015 at 12:37
  • @JoeStrazzere. I'm the only tester. I have time to do the tests and the risk is low, because it is a internal application.
    – James
    Dec 17, 2015 at 13:30

3 Answers 3

Reset to default
2

Do you have access to the original requirements?

If so, I would suggest you go back to these and build yourself a test plan. Because testing has come at the end of the process, my guess is they also haven't given you enough time to test everything (been there!). I would therefor focus on the high risk and areas of ambiguity. By which I mean, if you read the requirements and you are not Sure of what it is asking for, its also likely an area misinterpreted by the developer(s). Test that bit.

Once you have a degree of understanding of the systems and its stability, then I would begin to analyse what areas will have most value being automated. You won't be able to do it all in one go, but again, focus on the areas where automation will save you the most time and catch the highest risk issues.

Improve this answer
2

For the manual tests, I would suggest a cradle to grave approach witrh as large a business scenario as you can find.

No idea about your business terms, but e.g.: Create a user. Log in with the user. Do something with user profile as user like change password. Create a customer/subscriber/item. Add account to cust/item. Add billing details. Add address. Add product. Check out / close off / end-of-life the item.

Go through the lifecycle of whatever the noun is in the business segment, and do all the verbs to it. If you have a long enough but not too intricate test scenario, executing it will expose weaker areas of the system. Then make a risk based approach on where to focus with more tests.

Don't try to find corner cases. Stick to principle business functionality. That's what the system is there for after all.

HTH

Improve this answer
1

@James From my experience, I can suggest you test plan / strategy.

  • Go in Pragmatic but structure is essential.
  • Use Risk application test matrix.
  • Create Test scenario matrix.
  • Use MoSCoW principle.
  • If needed involve the end user / stakeholder for review application.

Later you can review again the test plan and strategy and make improvement from past experience.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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