http://citconf.com/wiki/api.php?action=feedcontributions&user=Gommo&feedformat=atomCitconWiki - User contributions [en]2024-03-28T10:31:17ZUser contributionsMediaWiki 1.35.11http://citconf.com/wiki/index.php?title=Tracking_Code_Quality&diff=6310Tracking Code Quality2008-06-29T08:42:16Z<p>Gommo: </p>
<hr />
<div>== Tracking Code Quality ==<br />
* Presentation by Marty Andrews<br />
* The Cyclomatic Complexity of a method is really the minimum number of unit tests needed to test very path in a method. <br />
* By reducing CC, usually by breaking large methods down, you reduce the number of tests you need to write !<br />
* Complexian - www.cogentconsulting.com.au/resources/complexian/index.html<br />
* FindBugs - usually needs human to interpret. Good to hook in but not run in CI. Human can run so often<br />
* SourceMonitor<br />
* JOODI - Package level checking. Good to enforce certain layers only access other layers e.g.<br />
* Spec# <br />
<br />
=== References ===<br />
<br />
# T.J. McCabe, "A complexity measure," IEEE Trans. Software Eng. vol. SE2, no 4, pp 308-320, 1976<br />
# B.A. Nejmeh, "NPATH: a measure of execution path complexity and its applications," Commun, ACM, vol 31, no 2, pp 188-200, 1988.<br />
# Wikipedia:Cyclomatic_complexity<br />
# Complexity Analyser for Java, http://www.martyandrews.net/resources/complexian.html<br />
# Complexity Analyser for C++, http://gnocchi.sourceforge.net/</div>Gommohttp://citconf.com/wiki/index.php?title=Show_us_your_Build!&diff=6272Show us your Build!2008-06-28T05:29:56Z<p>Gommo: New page: == Show us your Build == * Zero friction. You should be able to check out and it should just build * .Net Example ** Consistent layout ** src ** anything in lib folder will be referenced...</p>
<hr />
<div>== Show us your Build ==<br />
<br />
* Zero friction. You should be able to check out and it should just build<br />
<br />
* .Net Example<br />
** Consistent layout<br />
** src<br />
** anything in lib folder will be referenced<br />
** common.build between projects default.build for project<br />
** Convention of default.MACHINENAME.build for machine specific properties<br />
<br />
* Ivy seemed to get a few props. <br />
<br />
== Dynamic Languages ==<br />
<br />
* Traditional guidelines, do they apply? GOF, Refactoring, Agile Development, Effective Java<br />
* Strongly type - Object is ALWAYS a type<br />
<br />
* Static - compile time<br />
* Dynamic - runtime<br />
<br />
* Dynamic, compiler can't help me as much so might need more unit tests<br />
<br />
Check out these tools<br />
* Scala<br />
* simian<br />
* SourceMonitor <br />
* gradle<br />
* Is there a NIvy?<br />
* nmaven</div>Gommohttp://citconf.com/wiki/index.php?title=CITCONAsiaPacific2008Sessions&diff=6271CITCONAsiaPacific2008Sessions2008-06-28T05:28:09Z<p>Gommo: </p>
<hr />
<div>CITCON 2008 Melbourne Session<br />
<br />
== 10:00 Topics ==<br />
<br />
#[[What else contributes to quality before testing?]]<br />
#[[Exploratory Testing]]<br />
#[[Topic]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Managing data with regression integration testing.]]<br />
#[[Acceptance TDD]]<br />
<br />
== 2:00 Topics ==<br />
<br />
#[[Different Styles of TDD]]<br />
#[[Show us your Build!]]<br />
<br />
== 3:15 Topics ==<br />
<br />
#[[The People Side of CI]]<br />
#[[Topic]]<br />
<br />
== 4:30 Topics ==<br />
<br />
#[[Tracking Code Quality]]<br />
#[[Topic]]<br />
<br />
== Books & Polls ==<br />
<br />
#[[Books to read]]<br />
#[[Poll: What tools do you use]]</div>Gommohttp://citconf.com/wiki/index.php?title=What_else_contributes_to_quality_before_testing%3F&diff=6270What else contributes to quality before testing?2008-06-28T05:26:25Z<p>Gommo: </p>
<hr />
<div>== What else contributes to quality before testing ==<br />
!NOTE: This is pretty much just a dump from the session, needs some cleanup<br />
<br />
Jason Yip introduces the idea from past experience where some issues were found in production and this introduces the idea of how can you catch this earlier.<br />
<br />
Time boundary<br />
Multiple people<br />
<br />
Think => Produce => Inspect => <br />
<br />
Inspect phase is expensive to find issues<br />
<br />
What can you do in Think/produce phase to catch defect early?<br />
* Team Selection<br />
* Engineering practises<br />
* Commodity technologies<br />
* Amenable to good practice<br />
* Get in customer head space - Gaining emotional connection to context<br />
* Get domain experts<br />
<br />
<br />
How can this be tested?<br />
* PokaYoke - Make things mistake proof<br />
** Design by Contract e.g. Eiffel<br />
* Cultural norms - How do you get everyone thinking about quality?<br />
<br />
There are a lot of things we can do but are we addressing the right problem? (i.e. DBC)<br />
<br />
Examples of Commodity Techs<br />
ETL - Extraction Transform Loads<br />
* These ETL tools were hard to test and this was found out early by people asking these questions. How are we able to unit test this, CI it.<br />
<br />
Quality Definition - Quality is not the determination of your marketing, engineering, QA or sales divisions. It is determined wholly by your customer in what their both conscious of and not conscious of.<br />
<br />
Concurrent Set based approach - Attack multiple solutions at once. Safe, medium, risky<br />
<br />
Correct budgeting model<br />
* Traditional, scope project, assign total cost and work for years<br />
* Other, smaller cost to work out if possible<br />
<br />
Getting into customer heads pace, Examples<br />
* Watched a service station clerk do their job all day<br />
* Witnessed a bank teller reduced to tears because of their software<br />
* Another e.g. - In a complex system, Medical - nurses, doctors etc.. So they opened up the whole development system so the customer can input and change. Use cases in JIRA/Wiki<br />
<br />
* Domain Experts are really proxies because they can't represent EVERY ones opinion.<br />
<br />
* Can you get 'too' embedded. And not able to see the whole process.<br />
<br />
Two techniques<br />
# Embed domain expert in team<br />
# Depending on costs embed the team in the customers head space <br />
<br />
Is Quality == Maintainability? Aligned but not equal. Quality does contribute to maintainability but they are not equal. You can have a perfectly maintainable product but it does not have any business value.<br />
<br />
Quality is what the software is doing when its running. It can be functional but not reliable.</div>Gommohttp://citconf.com/wiki/index.php?title=Acceptance_TDD&diff=6269Acceptance TDD2008-06-28T05:24:30Z<p>Gommo: New page: == Acceptance Test Driven Development == Started with 1 word answers to how we feel? Vague, confused, mystified, requirements, Implementation independent.tools?? Slides by Jeremy initial...</p>
<hr />
<div>== Acceptance Test Driven Development ==<br />
<br />
Started with 1 word answers to how we feel? Vague, confused, mystified, requirements, Implementation independent.tools??<br />
<br />
Slides by Jeremy initially - Works @ Suncorp<br />
<br />
* What is it? How can a team do it? How do developers do their part?<br />
** Acceptance tests are criteria to get a story over the done line.<br />
** e.g. Last opportunity that we don't screw up in production<br />
** Fix requirements<br />
** Capture requirements<br />
* When do you right them? Upfront or last?<br />
* Summary - A lot to do with requirements and what the stakeholders want. <br />
<br />
* What is test driven development<br />
** Three laws by Uncle Bob<br />
# No production code without failing test<br />
# Only as much test as to see a failure<br />
# No more production code than to make the test part.<br />
<br />
* Adversarial coding. One writing tests, one writing production. Enforces not writing more code than necessary. <br />
<br />
* Story is captured in the story card so we don't lose it. But the acceptance test only has the first part of testing the story then we go and write the code to pass that piece. You don't write the entire acceptance test total.<br />
<br />
* Interesting idea was to have a list of acceptable failing tests. This might encourage TDD.<br />
<br />
* How maintainable are acceptance tests?<br />
** 1 test - Login -> Do 1 -> Read 1<br />
** 2 test - Login -> Do 2 -> Read 2<br />
** What happens when we want to remove Login? All these tests fai. Unit tests get around this by behind smaller and isolated.<br />
<br />
* Customer-defined Acceptance tests are not enough<br />
* Testers and Developers must define as well<br />
* Performance testers as well?<br />
* Customer must understand and accept the Acceptance tests. - Stops developer scope creep for point 3<br />
<br />
* Problem with just customer is that they probably only look at the 'happy' path?<br />
<br />
* Acceptance criteria should cover your functional and non-functional requirements<br />
<br />
* Acceptance tests are the prime interface between Developers and the rest of the team<br />
* Acceptance test code readable by non-Developers<br />
<br />
* D.R.Y. might have to be put on hold in acceptance tests because abstracting a way can make it hard for customer to read<br />
<br />
* Developers taking responsibility for implementing acceptance tests can leave testers free for exploratory testing<br />
<br />
* What does ATTD actually solve if you were running XP/SCRUM and involving the customer in each iteration and ensuring they are happy after each interation??<br />
<br />
* ATDD doesn't obsolete unit or integration tests but ATDD should drive the initial process. <br />
<br />
* With DBUnit you can feed the result set from one test to be the input to the next test<br />
* Google search - Business Natural Language<br />
* Thoughtworks - Twist<br />
* FIT for confluence? Greenpepper?</div>Gommohttp://citconf.com/wiki/index.php?title=CITCONAsiaPacific2008Sessions&diff=6268CITCONAsiaPacific2008Sessions2008-06-28T05:21:26Z<p>Gommo: </p>
<hr />
<div>CITCON 2008 Melbourne Session<br />
<br />
== 10:00 Topics ==<br />
<br />
#[[What else contributes to quality before testing?]]<br />
#[[Exploratory Testing]]<br />
#[[Topic]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Managing data with regression integration testing.]]<br />
#[[Acceptance TDD]]<br />
<br />
== 2:00 Topics ==<br />
<br />
#[[Different Styles of TDD]]<br />
#[[Topic]]<br />
<br />
== 3:15 Topics ==<br />
<br />
#[[The People Side of CI]]<br />
#[[Topic]]<br />
<br />
== 4:30 Topics ==<br />
<br />
#[[Tracking Code Quality]]<br />
#[[Topic]]<br />
<br />
== Books & Polls ==<br />
<br />
#[[Books to read]]<br />
#[[Poll: What tools do you use]]</div>Gommohttp://citconf.com/wiki/index.php?title=What_else_contributes_to_quality_before_testing%3F&diff=6267What else contributes to quality before testing?2008-06-28T05:19:25Z<p>Gommo: New page: == What else contributes to quality before testing == !NOTE: This is pretty much just a dump from the session, needs some cleanup Jason Yip introduces the idea from past experience where...</p>
<hr />
<div><br />
== What else contributes to quality before testing ==<br />
!NOTE: This is pretty much just a dump from the session, needs some cleanup<br />
<br />
Jason Yip introduces the idea from past experience where some issues were found in production and this introduces the idea of how can you catch this earlier.<br />
<br />
Time boundary<br />
Multiple people<br />
<br />
Think => Produce => Inspect => <br />
<br />
Inspect phase is expensive to find issues<br />
<br />
What can you do in Think/produce phase<br />
<br />
- Team Selection<br />
- Engineering practises<br />
- Commodity technologies<br />
- Amenable to good practice<br />
- Get in customer head space - Gaining emotional connection to context<br />
- Get domain experts<br />
<br />
<br />
How can this be tested?<br />
- PokaYoke - Make things mistake proof<br />
-- Design by Contract e.g. Eiffel<br />
- Cultural norms - How do you get everyone thinking about quality?<br />
<br />
There are a lot of things we can do but are we addressing the right problem? (i.e. DBC)<br />
<br />
Examples of Commodity Techs<br />
ETL - Extraction Transform Loads<br />
- These ETL tools were hard to test and this was found out early by people asking these questions. How are we able to unit test this, CI it.<br />
<br />
Quality Definition - Quality is not the determination of your marketting, engineering, QA or sales divisions. It is determined wholey by your customer in what their both conscious of and not conscious of.<br />
<br />
Concurrent Set based approach - Attack multiple solutions at once. Safe, medium, risky<br />
<br />
Correct budgeting model<br />
- Traditional, scope project, assign total cost and work for years<br />
- Other, smaller cost to work out if possible<br />
<br />
-Getting into customer headspace, Examples<br />
-- Watched a service station clerk do their job all day<br />
-- Witnessed a bank teller reduced to tears because of their software<br />
-- Another e.g. - In a complex system, Medical - nurses, doctors etc.. So they opened up the whole development system so the customer can input and change. Use cases in JIRA/Wiki<br />
--- Domain Experts are really proxies because they can't represent EVERY ones opinion.<br />
<br />
--- Can you get 'too' embedded. And not able to see the whole process.<br />
<br />
- Two techniques<br />
1. Embed domain expert in team<br />
2. Depending on costs embed the team in the customers head space <br />
<br />
Is Quality == Maintainability? Aligned but not equal. Quality does contribute to maintainability but they are not equal. You can have a perfectly maintainable product but it does not have any business value.<br />
<br />
<br />
Quality is what the software is doing when its running. It can be functional but not reliable.</div>Gommohttp://citconf.com/wiki/index.php?title=CITCONAsiaPacific2008Sessions&diff=6253CITCONAsiaPacific2008Sessions2008-06-28T00:15:56Z<p>Gommo: New page: CITCON 2008 Melbourne Session == 10:00 Topics == #What else contributes to quality before testing? #Topic #Topic == 11:15 Topics == #Topic #Topic == 2:00 Topics ==...</p>
<hr />
<div>CITCON 2008 Melbourne Session<br />
<br />
== 10:00 Topics ==<br />
<br />
#[[What else contributes to quality before testing?]]<br />
#[[Topic]]<br />
#[[Topic]]<br />
<br />
== 11:15 Topics ==<br />
<br />
#[[Topic]]<br />
#[[Topic]]<br />
<br />
== 2:00 Topics ==<br />
<br />
#[[Topic]]<br />
#[[Topic]]<br />
<br />
== 3:15 Topics ==<br />
<br />
#[[Topic]]<br />
#[[Topic]]<br />
<br />
== 4:30 Topics ==<br />
<br />
#[[Topic]]<br />
#[[Topic]]<br />
<br />
== Books & Polls ==<br />
<br />
#[[Books to read]]<br />
#[[Poll: What tools do you use]]</div>Gommo