It’s only odd if you assume 100% of the surveyed companies have a CI and build infrastructure set up. Quite possibly some percentage is only using it for source control and doesn’t have an automated CI process in place at all.
Wouldn't that only make sense with the percentages reversed (61% are users, 60% say it's their most used)? Otherwise, there are more companies where it's "most used" then there are that use it at all.
Set B: 82 of the surveyed companies use a CI solution of some kind
50/82 of those companies use GitLab CI (61%)
---------------------------------
The two percentages make sense because Set A and Set B is not the same set of companies, hence the denominator is not the same in the two percentage calculations.
> Fully 61% of companies say GitLab is their most used tool for CI and build
It's possible that I'm taking their statement too literally, but it seems a little misleading to me to use "fully 61% of companies" without additional qualification to refer to "61% of companies that use CI" when a sizable portion of companies (e.g. 18%) don't use CI at all.
I wonder how many survey responders AND result readers are confused by the software being called gitlab and the hosted repo SaaS offering being called gitlab vs community local installs of gitlab
There is something interesting there, I think, in that it shows the market penetration of their CI stuff. It's hard to justify shelling out for Bamboo or running Jenkins when you've got a very capable CI tool right in your repos. That tells me that a primary use case for Gitlab is running everything in one box, rather than bringing it in and having it talk to already-existing CI infrastructure.
> 5. Testing is still hard: 49% of respondents encounter the most delays during the testing stage of the development lifecycle.
> Half of those surveyed called out testing as the biggest source of delay in the development process, reflecting an industry-wide struggle to balance the benefits of manual testing with the need for automation.
Another example of how the purpose of testing is misperceived. You can't estimate how long it takes to test. It's more useful to simply time-box it.
The delays come about for several reasons:
* Testing often uncovers previously unknown problems that have affected the value of the product. The stakeholders choose to accept a delay to remedy the problems found.
* Manual testers often have insufficient fluency with their tools to enable them to rapidly create data, set up and tear down environments, find patterns in data and generate meaningful reports.
* Organisations often emphasise the creation of painstakingly detailed test cases full of duplication.
* Dedicated test automation teams often go down the rabbit hole building low-value, high-cost, high feedback latency test harnesses in which tests are translated verbatim into code from manual test cases, driving tests of business logic through slow, flaky, GUI automation.
There is a great deal of dysfunction in how testing is perceived, managed and performed - both by practitioners and those who must make decisions based on the outcomes of testing.
27 comments
[ 2.7 ms ] story [ 70.4 ms ] threadhttps://www.surveymonkey.com/results/SM-8LLKL2N87
There's only a tiny link at the bottom of the page for this.
a survey by gitlab is biased towards gitlab, how strange
> A reminder, though, that 60% of our survey takers are GitLab users.
---------------------------------
Set A: 100 companies are surveyed
60/100 companies use GitLab (60%)
---------------------------------
Set B: 82 of the surveyed companies use a CI solution of some kind
50/82 of those companies use GitLab CI (61%)
---------------------------------
The two percentages make sense because Set A and Set B is not the same set of companies, hence the denominator is not the same in the two percentage calculations.
It's possible that I'm taking their statement too literally, but it seems a little misleading to me to use "fully 61% of companies" without additional qualification to refer to "61% of companies that use CI" when a sizable portion of companies (e.g. 18%) don't use CI at all.
How do you prioritize order, plan or coordinate stuuf if you are not using waterfall, scrum, kanban or whatever?
I always had one combination or another..
> Half of those surveyed called out testing as the biggest source of delay in the development process, reflecting an industry-wide struggle to balance the benefits of manual testing with the need for automation.
Another example of how the purpose of testing is misperceived. You can't estimate how long it takes to test. It's more useful to simply time-box it.
The delays come about for several reasons:
* Testing often uncovers previously unknown problems that have affected the value of the product. The stakeholders choose to accept a delay to remedy the problems found.
* Manual testers often have insufficient fluency with their tools to enable them to rapidly create data, set up and tear down environments, find patterns in data and generate meaningful reports.
* Organisations often emphasise the creation of painstakingly detailed test cases full of duplication.
* Dedicated test automation teams often go down the rabbit hole building low-value, high-cost, high feedback latency test harnesses in which tests are translated verbatim into code from manual test cases, driving tests of business logic through slow, flaky, GUI automation.
There is a great deal of dysfunction in how testing is perceived, managed and performed - both by practitioners and those who must make decisions based on the outcomes of testing.