Fhyujk

According to SDLC Process, testing by QA testers only stars at 'Testing' phase. Is that saying before 'Testing' phase, QA testers have no work to do.

When actually a can tester starts his job ?

Is it possible to start testing works before 'Testing' phase ?

Answering your particular question "Is it possible?" I would say "Yes, it is.". There are many aspects that could impact how active QA could be involved on the prior phases. For example:

• Is that an automation QA or manual QA


• How strong soft and hard skills of particular QA engineer are


• How well the job was done from the top bottom phases


• How well is the inter-project communication established

For example on Analysis phase you could work with analysts to gather proper requirements in proper notation that would be suitable for further usage when you will be designing the tests.

On Design phase you could consult your architects or tech leads on how to do your system more testable. Prepare a test strategy and estimate test budget of the project.

On Environments phase you could obviously build or help your devops to build the abstract deployment process, plan how your tests would integrate into CI/CD, plan what environmental properties are to be configured for better fitting testing needs, etc.

I didn't start from System Investigation since on that phase normally they involve very limited engineering participation so that QA are unlikely to be invited.

Disclaimer: Phases description is taken from this Wikipedia article.

The job of testing starts before you write code when you follow

BDD- Behavior Driven Design

and

TDD - Test Driven Design

There are many books on the above topics so I'll avoid trying to explain them in details other than to say "Test first"

The best time to start is? Now!

Traditionally people view testing as a phase that happens at the end
of development. In agile most have changed it that the chunk of
development done is smaller, but the testing still happens last.
Nothing has fundamentally changed about how testing is done.

...

In contrast in agile, testing is just an activity that needs to
happen, along with coding, documentation and everything else. Thinking
about it like this makes it possible to consider the idea of doing
testing tasks before development work. A great way to visualise this
on a taskboard is that instead of having a separate column for test,
rather just make testing tasks a different colour sticky note.

https://leanpub.com/AgileTesting/read

Other reads for inspiration of pre-post code testing activities:

• https://less.works/less/technical-excellence/thinking-about-testing.html


• Modern Testing Principles

I would say it should ideally start, when project starts. Because most of thing in project can, and should be tested in some way. No one in project team is flawless, and bad decisions will probably cost time or money later.

You can test:

• ideas – participation in meeting will add another point of view, and may make software more testable.


• requirement – they can be ambiguous and thus poorly understood by delveloper


• software


• lot more things, like processes within project team, used technologies,…

Testing is not done only when you sit before computer, and management should count with it. You probably already been thinking about project before someone told you that „'Testing' phase“ started.

You will do better work, when you have better knowledge of tested application.

The old SDLC waterfall method has each phase start at the end of the prior phase. This can lead to a lot of wasted time and a 'throw it over the fence' attitude.

There's a concept of coding to the test, as in the TDD which was mentioned in Michael Durrant's answer, which basically means that the test team gets in at requirements time and helps design tests that will satisfy the requirements, then the code is designed and written so that it satisfies the test, thus the test team is involved very early on.

It's a truism that the earlier an issue is identified the cheaper it is to fix. I can't cite a source, but I've seen it presented as an order of magnitude at each phase. If it costs $1 to fix a problem in requirements, it will cost $10 to fix it in design, $100 to fix it in development, $1000 to fix in test, and $10,000 to fix it in production. Whether the actual costs really follow such a curve isn't something I can speak to, but the general principle is sound, so it makes good sense to involve the test team right off the bat.

In an agile environment, this sort of forward thinking is baked right in to the process.