Age Verification
This website contains age-restricted material including nudity and explicit content. By entering, you confirm being at least 18 years old or the age of majority in the jurisdiction you are accessing the website from.
I am 18+ or older - Enter
I am under 18 - Exit
Our parental controls page explains how you can easily block access to this site.

Last posts - Page 486

  Forum

Sexy3DBoy
Joined in Jun 2011
1319 post(s)

Special Event Card previews

Everything about iStripper
August 1, 2021, 28 answers
Dans mon premier post, j'ai juste relater que sur la fin 2018, les SECs arrivaient sur le carroussel et que l'on pouvait uniquement y télécharger les démos. Et que dans la foulée (quelques jours peut-être) il y avait à faire une mise à jour du logiciel recommandée par iStripper. Et qu'à la suite de cette mise à niveau de l'application PLUS DE PREVIEW DE SEC!!! Le spectacle était terminé.

Entre nous:
On se fiche totalement des phases de développement du logiciel, ils ont juste adapté leur code pour que ce dernier bloque les SECs au niveau du carroussel et des previews, pointbarre. Et la génèse de tout ceci est purement commerciale.

P.S.
Perso, je repecte le business privé d'iStripper avec ses règles de fonctionnement, mais ici bloquer des previews, je trouve cela "PAS BIEN DU TOUT".😆

In my first post, I just related that on the end of 2018, the SECs were arriving on the carousel and that you could only download the demos there. And that in the wake (a few days maybe) there was to be a software update recommended by iStripper. And that following this upgrade of the application NO MORE SEC PREVIEW!!! The show was over.

Just between us:
Who cares about the development phases of the software, they just adapted their code to make it block SECs at the carousel and preview level, full stop. And the genesis of all this is purely commercial.

P.S.
Personally, I respect iStripper's private business with its rules of operation, but here blocking previews, I find it "NOT GOOD AT ALL".😆


Dorsai6
Joined in Apr 2013
3459 post(s)

Special Event Card previews

Everything about iStripper
August 1, 2021, 28 answers
@TheEmu

It is less clear that there should always be a separate test phase - testing should be part of all the phases - though it is clear that it should be done and often there will be two or more phases dedicated to testing.

I also have spent about 40 years struggling to get the importance of testing properly acknowledged - mostly to get that importance recognised as part of the requirements phases rather than as an "add-on" extra phase at the end. Ironically, considering Sexy3DBoy's NASA comment, this was mostly in respect to ESA and NASA projects and they were both quite poor at it compared with what I had been used to previously.

We're way off the original topic, but I can't help chiming in. This has been a hot issue for me for about the same length of time. I'd phrase it a bit differently. Instead of testing, I prefer to talk about Quality Assurance. Testing is a form of Quality Control and Quality Control is part of Quality Assurance. The Six Sigma community believes that with enough quality assurance at the front end you can eliminate testing at the back. Although I don't buy that completely they have a point.

I have been convinced for a long time that testing is an inefficiently use of quality resources. I think peer reviews of requirements and designs are much more effective for finding significant problems. These days I do mostly enterprise level requirements work. From personal experience, the quality of my work products is directly proportional to the amount of peer reviews I can get from my collegues. I also know that the most significant problems I've detected in other people's work has been from review of their designs.

Here is a favorite quote of mine from Componsit/Structure Design by Glenford Myers, 1978, page 2:

"Programmers spend the majority of their time correcting their mistakes.

"Moreover they never finish. Examinations of typical programming projects will show that, over the dduration of the project, programmers spend over 50% of their working hours looking for and correcting their mistakes. The usual "solution" to this is remarkable. We try to solve the problem by rushing through the design process so that enough time is left at the end of the project to uncover the errors the were made because we rushed through the design process."

40+ years later and we still work this way.