When a new project starts in an organization, when does the testing role come in? Is it at the same time as the development stage, or later?
I lean toward involving Test from the beginning. When building something, if you don't support ways of testing it from the beginning, you end up having to rip it up and add that later. This hurts the company.
Let's discuss "testing".
As a developer, I consider test to be essential feedback, many kinds of tests to be important, and the Test department an essential ally in keeping the results of mistakes, poor assumptions, miscommunications etc. from making it out the door to customers.
I consider some areas to be the developer's responsibility, and some areas to best be done by someone independent, with a different mind-set and set of skills.
Developer's responsibility and tools: inside the edit / compile / debug loop
Don't ever tell me developers shouldn't (or don't) do test:
- When using a syntax-highlighting editor: it examines the source code and provides immediate feedback to tell me whether e.g. my syntax is correct. Is this not "testing"?
- When compiling and linking: the compiler and linker perform highly complex and detailed processing of the code and returns pass/warning/error results in addition to the binaries. Is this not "testing"?
- I use TDD / unit testing, essentially a customized extension of the compiler's code checking. I would MUCH rather write a second set of programs (unit tests), that help automate testing and debugging, than repeatedly manually step through the code by hand to debug it by hand. TDD is also much more productive and better use of my time than repeated manual testing. It remembers how to test something after I haven't touched that code for six months (or the original developer has moved on).
Best done by others:
- System test
- Manual exploratory testing
- Usability testing.
The problem is: I know exactly how the system should work - and will tend to politely give it only the expected inputs. I may not e.g. pound on the keyboard, skip configuration settings, enter commands too fast, enter foreign characters, enter 257-character names, click and drag a large document to an input field...
I build things, and my time is limited. I need someone else to help try to break them, in ways I did not expect.
When a new project development starts in an organization when does the testing role come in?
It depends on the company, industry, development approach, etc.
Two commonly referred to methods for development are Waterfall and Agile
In Waterfall you do the testing once the development of a feature is done. In Agile you do the testing before* and during development.
In your situation the best course of action is usually a long detailed conversation with developers about what testing makes sense to cover the areas of Unit, Functional, User Acceptance and Exploratory testing.
* by writing failing tests that will pass once the functionality has actually been created.
Testers have a role in every phase of a project (be it waterfall, iterative, or full on agile):
- Project planning - ensuring proper consideration is given to procuring and setting up of test architecture, and for both testing and resolving faults found during testing.
- Requirements gathering/setting - testers can help ensure the requirements are described and recorded accurately (asking questions like "When you say you need many Xs, can we quantify that?")
- Development - ensuring there are frameworks/best practice for unit tests, integration tests etc
- Testing - no comment needed
- Deployment - Looking for faults caused by or during the deployment Post deployment support - investigating live faults, ensuring they are logged correctly and understood so any fixes can be tested to ensure they work (oh and the testing of those fixes)
- Post project reviews - looking for lessons that can be learned for the next project - especially with regard to improving the testing elements and tester involvement.
You should first ask yourself what is "testing". If you refer to manual/automated testing of the implementation then it cannot start before development or part of development is done.
However, referring to testing in such a way is rare nowadays. The Quality Assurance should already take place when the analysis/specification is being done and they should take an active part in every later stage (e.g. validating architecture, making sure that unit tests are written and running correctly).
The QA people should make sure that the specification contains all the features requested by the customer/users and that there are no blind spots in the specification (e.g. a hidden sentence that will increase the development cost three times).
One of the biggest problems in any development project is when development is done and you realize that what you have implemented is not actually what the client/users want and had paid for. In an agile project with continuous releases and verification by users, this can be discovered quickly but it can be still quite costly. In a waterfall project, this can bankrupt you.
When a new project starts in an organization, when does the testing role come in?
It definitely depends. Often too late if you ask me. In my world the ideal timing is right at the start of the project. The earlier the better. There might not be a lot of hours spent early but they can be very valuable. The testing role can help in making the requirements testable. The role will also allow preparing the test environment in time. An experienced test leader may be able to forecast that testing will cost, as an example, say, 10% of development hours and 10% of calendar time. This will allow the project to work backwards to find the critical milestones. Incidentally, this is true both for waterfall and agile development, at least in my experience.
There are examples where creating the test environment and preparing for tests takes more resources than the actual implementation, example may be outer space probes.
There are, as well, projects without next to no testing done at all. In my experience this is not a good idea.
During the intake of the project I would like to have someone of each expertise group present, so also someone with a software quality and testing background. So my answer to your question is: At the start of the project identification phase.
Test-first seems to be a common practises now a days, so you need someone with the ability to teach/coach testing practises from the start of your project anyways.
How many hands you need for manual testing should depend on the project type, but for most common business projects I would try to automate your testing as much as possible from the start, as I think continously delivery greatly enhances the feedback cycle in finding the most valuable features.
Testing no longer means testing
Confused? We can imagine! The purpose of testing used to be fairly clear–“Testing is the process of executing a program with the intent of finding errors” [Meyers79]. This changes when adopting agile and lean development.
Concurrent engineering necessitates parallelizing work. Dedicated cross-functional teams encourage single-specialists to broaden their expertise. These cause the purpose of conventional development activities–such as test–to shift.