12

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 ?

  • 10
    "according to SDLC" - where is this coming from? This sounds like an old book and does not reflect modern agile practices where testing starts before development. Do you work in an organization that considers itself agile? – Michael Durrant Feb 27 at 12:28
  • @Michael Durrant It's an interview question – Albin K S Feb 27 at 14:18
  • 1
    It would really suck for that QA tester to wait until the testing phase to tell the hardware developers that they need extra hardware components on the board in order to be able to perform tests to verify requirements. A 6 month delay of the program waiting for board turnarounds is likely to cause several people their jobs. – Dunk Feb 27 at 20:04
  • 2
    In addition to the things mentioned in the existing answers (although tugo touched on it), there's a lot more to a QA tester's job than executing test cases - things not even related to the product you'll be testing (well, not really). Looking into test tools, keeping up-to-date on the latest testing technologies and methods, trying out new processes ... basically all the "meta" stuff that makes the real goal (write and execute test cases) easier. Test infrastructure, improving common test libraries, paying down tech debt (while you have time to breathe), ... – Steve Feb 28 at 0:59
  • In my somewhat limited experience as a developer, QA start their work on testing features I develop at the same time I become involved in developing these features. Depending on what is actually being asked, they might have very little involvement - being aware of the requirements, for example, or they may take a more active part in both refining them and planning. At the very least it's because a tester needs to know what to test when the "testing phase" comes. – VLAZ Feb 28 at 13:49
15

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.

3

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.

2

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:

1

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"

  • Also all of the various "Extreme Programming" models require tests to be written before any code. – Steve Barnes Feb 27 at 21:11
0

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 requirements can be poorly understood by the QA participant as well. Jumping in as early as possible will help to clarify requirements as well as user interaction (if that exists) as soon as it is expressed rather than a long time after the original participants have left the room. – DDay Feb 27 at 18:59
0

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

0

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.

0

QA testers are always in picture. Before testing phase there are lots of things to do:

  1. Understanding upcoming sprint requirements.
  2. Creation of test cases of the features.
  3. Reviewing test cases from PM team.
  4. Creation of estimates and getting it approved.
  5. At the same time dev guys would be working on creating new build features.
  6. Once the build is delivered then QA starts working on them and so on.....

So various qa services organizations are following this approach and hence keeping their testers in picture all the time.

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.