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
-
@spongessuck unittests/e2e Tests.
-
@max19931 I wouldn't call those proactive.
-
I think the majority of quality problems come from having vague and ambiguous product definitions. Product managers should present a feature to devs, who can break it down into pieces, and each piece can be tested. A user story isn’t completed until it has a test in place. Unit tests should easily link to user stories. A good user story fits the INVEST acronym , with “T” being testable.
Good quality code starts with devs asking “can we test this simply” and if not, it’s probably too large to code and needs to be split smaller.
Also, Make sure you have both integration and contract tests on top of your unit tests. A repo should test itself (unit and integration tests) and should test things it depends on (contract test) -
Your insight that tests might take up too much time for the org is valuable.
It's important that testing doesn't feel exaggerated.
Once an org gets heavily invested in testing it's possible that you lose sight of the actual risk vs reward - and will spend huge amounts of time and money on tests bogging down the development process, when the bugs you catch would actually not even be that bad/costly/embarrassing.
So it's important to focus on the low hanging fruit first.
for example: if you're adding a new article template for a website have an e2e test that ensure the page can actually render given two types of input. -
When it comes to unit tests or testing specific components in detail I think you shouldn't add those for every single thing. it can become an excessive time sink.
You're on track that there should be a risk analysis. Talk to devs and look for for standout components/units.
For Example:
* The PR:s with a large number of changes due to mistakes during development
* relies on a file which is constantly changed in the codebase (you can see this using various git tools)
* complex or fragile tech (like if you often have caching bugs - ask devs to see which upcoming features are cache sensitive)
* sensitive info that'll cost the org if there's a bug. (for example GDPR stuff like personal info)
* In the end it also boils down to which features are easy to write automated tests for (clear input/output and NOT using 3rd party code) -
@spongessuck well complete proactive testing might be impossible, but reactive testing - eg exploratory testing that we do at the end of our sprints to uncover defects must have a counternpart to be defined reactive therefor i just used the term proactive to describe things like unit and e2e 👍🏼
-
@devphobe i completely agree, my biggest issue is i cant get management to put in time to reach the INVEST model of our stories, specifically i cant get a acceptance criteria, as most of our stories actually ets implemented with a very loose acceptance and us deva get to influence how the stories are accepted during development 😅
So ive got issues trying to produce test cases beforehand as stories are not always testable until story is implemented 😳 -
@jiraTicket completely agree!
We currently do have a pretty large testing effort, we have 3 months sprints and the whole 3rd month all devs do exploratory testing and non functional tests(portability, compatability, etc)
Issue is that these defects we do find often could have been fixed way earlier, or come years down the line on some unused feature, and fixing these defects upfront would effectively decreasing price pr bug due to dev in fresh memory, extra rework costs, etc.. -
@jiraTicket so rather than strictly doing risk analysis on all stories, spend the time in the risk analysis productively by askimg where we see risks and onyæ do assesment and mitigation plans on these ?
Sounds like way less time consuming than what im doing at the moment..
Also one of the main issues is when we do see a story we want to riak asses, we often dont know the implementation detail yet, how would you go about this ?
Related Rants
Two unit tests, no integration tests.
Calling QA/ Test managers for help !
Im a junior dev at a company where im slowly transitioning into also being our test lead. I just got my ISTQB foundation and im starting to write out the test strategy for our company.
Currently we’r doing alot of reactice testing, and to implement more proactive testing i wanted to implement a risk strategy as well.
Problem is that i feel this strategy takes too much time for our organization (doing risk analysis for each story we’r implementing just isnt possivle) , and we don’t have time for me actinh as a full time Test manager while also doing software dev tasks.
Question is: what good proactive strategies can we implement that doesnt require too much time investment - or could we use risk strategy only for specific stories implemented / custom orders / etc and stick with a reactive strategy solely ?
Later this yesr ill be sent on ISTQB test manager course to better qualify my position but until then id really want to get a test strategy somewhat implemented
Any help is MUCH appriciated!
question
test
testing
tester
quality
qa
risk