Cfxtrjtrk

We have multiple website projects running in our company and, as it's small firm, we cannot afford a separate QA environment. So, we are now testing in development server.

Right now, what we do is; a developer completes the work and then we test (Waterfall). But some projects are Agile where continuous feedback from client will be coming, and the developers need to work on the existing item if it's in testing phase too because the deadline of a project will be too short and the client won't extend the deadline.

What kind of approach to be followed in this scenario?

This depends on what kind of limitations you are experiencing. You can come up with virtualization. This will let you run several environments in a single host.You can also approach with containerization where you use the same host but isolate your instances with effective segregation of computational resources. Both of these options require some non-trivial work to setup everything.

If you do not have skilled people who could help you with set up, then you can choose on of the following ways:

• Decrease the time you spend on regression testing with test automation


• Encourage your devs to cover their features with unit-testing


• Encourage your architect (or someone who plays the role of architect) to design your apps in the way the features are more or less isolated from each other (like micro-services architecture) so that development of one feature would have minor impact on the features which are under testing


• Plan your testing in terms of scheduling so that there would be sessions for qa testing and sessions for dev testing. Devs usually do not need their envs to be online continuously. So you can agree on when you use the environment (some long sessions) and when they do (some short sessions).

If your current Agile practices and approaches are:

Some projects are Agile where continuous feedback from client will be coming, and the developers need to work on the existing item if it's in testing phase too because the deadline of a project will be too short and the client won't extend the deadline.

Then you are not agile

Although Agile does indeed depend on fast and immediate feedback from the customer, if this is misapplied and turned into "continuous feedback from the client that needs to be applied immediately" - and this bypasses the agile development process - it does not 'make' you agile. In good agile shops you can take a concept from idea to production in minutes if you have spend the time up front architecting a well designed and tested system. This is where the rubber hits the road for all the good practices you can read about. They may sound good 'in theory' but to realize their touted benefits they have to actually be applied and that is hard.

Agile means that you develop software differently. This does not automatically mean high costs, expensive equipment or additional servers.

I recommend you focus on:

• Learning more about Agile Development


• Learn more about TDD


• Learn more about BDD


• Learn about Scrum


• Learn about Kanban


• Learn about Agile Testing Pyramid


• Learn about Agile Testing Quadrants

"the deadline of a project will be too short and the client won't extend the deadline." has been the challenge of developing software for the last 50 years. Your responsibility is to educate the client or their representative about what quality testing means. If they refuse to talk I recommend finding other clients. If you continue with this client and don't change the approach it will just get worse and worse as time goes by.

Another note on cost - you can and nowadays should - use cloud services for your environment and pay a few dollars a day - or even a few cents - for a test environment.

You mentioned there is a handoff from development to test even within the sprints.

Would the team be willing to do paired work? Sit with the developer early in the sprint, talk about unit tests they are creating, tests you might run, and have them explain how they have understood & are implementing the story features.

Another idea I've heard (which isn't pure agile I realize) is the idea of a "freeze" for 2 or 3 days near the end of the sprint. So if you have a 10 day sprint, say day 8 & 9 the code is "frozen" so you can do some testing. That leaves day 10 for any last fixes the developers may need to do. Ugly, yes....but ultimately it is about doing the best you can for the customer with the resource you currently have.