What approach do we need to follow for projects without a test environment?
Clash Royale CLAN TAG#URR8PPP
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?
qa-process testing-environment
add a comment |
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?
qa-process testing-environment
add a comment |
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?
qa-process testing-environment
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?
qa-process testing-environment
qa-process testing-environment
edited Mar 15 at 9:03
trashpanda
1,5221929
1,5221929
asked Mar 15 at 8:42
ManuManu
748
748
add a comment |
add a comment |
4 Answers
4
active
oldest
votes
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).
add a comment |
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.
add a comment |
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.
add a comment |
As much as possible try to collaborate with the developers. Try be a part of life cycle early. You can first go through requirement and come with your test cases. Then review them with developer. Also can provide input to developers unit test. Share your test scenarios with dev and try to minimize bugs. During the testing also you can do pair test
Also even in dev environment while you are doing testing you may have to hold other releases of other dev unless test complete
In a different note at least for few project try dedicate test environment these are like very much key basic things when you have a test team
add a comment |
Your Answer
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "244"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38276%2fwhat-approach-do-we-need-to-follow-for-projects-without-a-test-environment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
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).
add a comment |
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).
add a comment |
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).
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).
edited Mar 15 at 12:46
answered Mar 15 at 9:55
Alexey R.Alexey R.
8,17311033
8,17311033
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
edited Mar 15 at 13:43
answered Mar 15 at 10:07
Michael DurrantMichael Durrant
14.7k22165
14.7k22165
add a comment |
add a comment |
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.
add a comment |
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.
add a comment |
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.
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.
answered Mar 15 at 11:52
CKleinCKlein
1,07169
1,07169
add a comment |
add a comment |
As much as possible try to collaborate with the developers. Try be a part of life cycle early. You can first go through requirement and come with your test cases. Then review them with developer. Also can provide input to developers unit test. Share your test scenarios with dev and try to minimize bugs. During the testing also you can do pair test
Also even in dev environment while you are doing testing you may have to hold other releases of other dev unless test complete
In a different note at least for few project try dedicate test environment these are like very much key basic things when you have a test team
add a comment |
As much as possible try to collaborate with the developers. Try be a part of life cycle early. You can first go through requirement and come with your test cases. Then review them with developer. Also can provide input to developers unit test. Share your test scenarios with dev and try to minimize bugs. During the testing also you can do pair test
Also even in dev environment while you are doing testing you may have to hold other releases of other dev unless test complete
In a different note at least for few project try dedicate test environment these are like very much key basic things when you have a test team
add a comment |
As much as possible try to collaborate with the developers. Try be a part of life cycle early. You can first go through requirement and come with your test cases. Then review them with developer. Also can provide input to developers unit test. Share your test scenarios with dev and try to minimize bugs. During the testing also you can do pair test
Also even in dev environment while you are doing testing you may have to hold other releases of other dev unless test complete
In a different note at least for few project try dedicate test environment these are like very much key basic things when you have a test team
As much as possible try to collaborate with the developers. Try be a part of life cycle early. You can first go through requirement and come with your test cases. Then review them with developer. Also can provide input to developers unit test. Share your test scenarios with dev and try to minimize bugs. During the testing also you can do pair test
Also even in dev environment while you are doing testing you may have to hold other releases of other dev unless test complete
In a different note at least for few project try dedicate test environment these are like very much key basic things when you have a test team
answered Mar 20 at 4:25
udararajudararaj
436
436
add a comment |
add a comment |
Thanks for contributing an answer to Software Quality Assurance & Testing Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsqa.stackexchange.com%2fquestions%2f38276%2fwhat-approach-do-we-need-to-follow-for-projects-without-a-test-environment%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown