Bdtyktl

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 can a tester actually start his/her 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 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.

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

A tester starts their job when they join the company. They are responsible for a quality product including - but not limited to - testing the latest feature. For all the other things they can do other than testing a specific feature just written, see the other answers.

Also, 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"

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.

A good time to start the from the beginning of the project startup. In this way,you will get enough time to do proper planning for the processes followed during the testing life cycle.
It’ll also ensure that the product to be delivered to the customer satisfies the quality criteria

I would say that a tester should begin "his job" as early in the process as possible. As a former engineering manager, I worked to have QA be part of the requirements gathering, then business analysis, etc. Testers have a different view of an application than a developer and can have insight into usability and UI design that a developer may overlook. Also, a tester can start to develop high level test plans and test cases immediately after wire frames are mocked up while developers go to their cubes to start cranking out code. Testers can also begin to build test environments, provision VM's, etc. to be prepared to receive products from the development team.

In today's modern world of agile development, there really aren't the classic "phases" any longer. I would be curious as to what kind of SDLC this company uses. I became a certified scrum master and pushed scrum onto my organization and that completely blurred the lines between the traditional developer and tester labels. Everyone was part of the scrum team and the scrum team worked as a single entity, succeeding or failing together, so there was no legitimate reason to keep QA in the dark or to have their work lag development.

So in short, I suggest that a tester's job begins on the same day that a developer's job begins which should be on inception of the project.