Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
Dunno how about your stuff.
But in my projects happens continuous integration.
All the time during development, the pipeline of automated unit and integration testing needs to be repaired. If some commit breaks it, it is priority to repair first.
Staging environment is updated super often automatically in its releasees.
Secondly... I write new testing at the same time as new code is introduced. Ideally we follow TDD and we write tests BEFORE the code is written.
Thirdly. I write only tests that are easy to write. Unit and integration testing.
And bothered to go minimal performance testing.
If I would have plenty of time, I would care to write end to end testing too -
C0D4681383yUse case testing / verification.
Wether that's automated or manual is another problem.
Depends on the software and their skill sets really as to what that actually looks like.
For fragile systems there could be a regression testing for some highly used areas to ensure no unpredicted side affects have been introduced.
This usually sits after the dev cycle so they're "sprints" are always reliant on the dev sprint before hand. -
They're testing features that are still in the backlog and filling Jira with tickets about how those features haven't been implemented yet.
-
hjk10157313yAfter release there is no work being done on things that didn't make the release of next milestone?
In TDD tests come first so if that is used as soon as the first feature is known the tester can work on it.
Perhaps some things where tested manually for the release. Now is the time to automate those tests so regressions don't happen. As automated tests are a trade-off between time and coverage if there is more time you can get more coverage.
Perhaps some things where rushed for the release. Now things can be cleaned up. Deduplicated and better facilitated so new similar tests can be added faster.
Just some ideas never worked with a dedicated tester. -
dmoen2193yI think i was a bit unclear. I meant people who works as software testers, not devs who writes tests.
-
Voxera115733yOur testers continuously test new features added, then one week before release we take the release branch and move it to a separate test environment that is even more production like and go through a week of more intense testing.
After release they go back to test new features as they are added.
The goal being that the week of intense testing should show as few problems as possible.
On the other hand, we release every two weeks. -
Non-dev testers should still work on new ways to test the product. Think about edge cases. Optimize the manual test procedures. Think about tests that could be automated and suggest them to people who can do so.
Automating tests normally is quite different to creating and maintaining the actual product. Most automated tests prepare a state, do some action and then check the resulting state for deviation from the expected state.
If you are mentally able to systematically test the product manually, you should also be able to aquire enough coding skill to copy existing automated tests and modify them to test new cases.
You could also learn OS- or browser-level automation, which would enable you to fully automate some of the user-level tests that commonly are performed by an actual human entering texts and clicking on things.
There are no idle times in IT!
Related Rants
What does a software tester do between releases?
I mean, it can take weeks before another release comes up. What do they work with between releases?
rant
testing
question