download zip of files only
Mon Jun 27 16:43:20 GMT 2011
From /weblog/software_engineering
First, stop writing lousy code Design for failure Keep it Simple Test… test… test…. Get in the trenches with ops Change is bad…. but change is good Safety First http://www.javacodegeeks.com[..]/06/lessons-in-software-reliability.html
(google search)
(amazon search)
Wed Apr 27 16:36:26 GMT 2011
From /weblog/software_engineering/testing
Idea of how to refactoring test cases, summary : Refactor production code with the tests passing. This helps you determine that the production code still does what it is meant to. Refactor test code with the tests failing. This helps you determine that the test code still does what it is meant to. http://googletesting.blogspot.com[..]07/04/tott-refactoring-tests-in-red.html Collections of idea of testing private methods - http://www.infoq.com/news/2008/01/private-methods-tdd-design , may be it is a signal of refactoring? The other way of testing private , via compare with difference implementation - http://manversusvirtualmachine.blogspot.com[..]1/unit-testing-private-methods-like.html Explain the problem of non-Determinism in testing, common reason of why tests becoming non-Deterministic, and common solution - http://martinfowler.com/articles/nonDeterminism.html
(google search)
(amazon search)
Sun Jan 16 16:44:41 GMT 2011
From /weblog/software_engineering/project
1. Cutover to any new system should be in small increments. Impossible? Don’t give up on increments too quickly – and don’t leave this to “customers” to decide! The technical risk of a big-bang cut-over is immense. And it’s almost always easier to divide the system in some way to facilitate incremental deployment than it is to deal with the virtually guaranteed chaos of a big-bang cutover. 2. Simplify before you automate. Never automate a work process until the work teams have devised as simple a work process as they possibly can. Automating the right thing is at least as important as automating it right. 3. Do not freeze work design into code! Leave as much work design as possible for work teams to determine and modify. If that is not possible, make sure that the people who will live with the new system are involved in the design of their work. 4. Rehearse! Don’t just test the technical part, include the people who will use the new system in end-to-end rehearsals. Be prepared to adapt the technical system to the social system and to refine the social system as well. Be sure everyone knows what to do; be sure that the new work design makes sense. Leave time to adjust and adapt. Don’t cut this part short. 5. Organize to manage complexity. Structure work around work teams that can adapt to changing situations, especially if the environment is complex, could change rapidly, or is mission critical. At minimum, have emergency response teams on hand when the new system goes live. http://www.leanessays.com/2011/01/tale-of-two-terminals.html
(google search)
(amazon search)
Mon Jan 03 01:13:15 GMT 2011
From /weblog/software_engineering/testing
An simple example of doing javascript unit test - http://jroller.com[..]ray?entry=testing_javascript_with_groovy However this approach is too fake for me and easy to miss many thing, IMHO putting test a real environment is better A site for javascript testing http://www.testdrivenjavascript.com Test time in javascript - http://googletesting.blogspot.com[..]avascript-simulating-time-in-jsunit.html And this is an example of using JDK6 scripting framework for testing javascript, pretty interesting , but probably not reflecting IE/MOZ behaviour - http://technology.amis.nl/blog/?p=1869 Use a scripting engine to test javascript - http://labnotes.org[..]nsanely-fast-full-stack-headless-testing
(google search)
(amazon search)
Tue Nov 16 16:48:42 GMT 2010
From /weblog/software_engineering/testing
Here is a more complicated framework, not looking good but still keep it here as the concept is interesting - http://sourceforge.net/projects/cubictest The most excellent implementation for my need - http://www.concordion.org/ http://www.jamesshore.com/Blog/Five-Ways-to-Misuse-Fit.html - Don't use it as junit, "The whole point of Fit is to use HTML to speak the customer's language and fixtures to translate that language to code. " http://jroller.com/njain/entry/is_fitnesse_ready_for_enterprise - Version control is #1 issue at that article When use Fit/Fitness - http://madcoderspeak.blogspot.com[..]-do-i-use-for-acceptance-tests-atdd.html
(google search)
(amazon search)
Tue Mar 09 01:37:46 GMT 2010
From /weblog/software_engineering/SCM
Software CM creates the medium through which software development changes & activities must flow. Therefore, Software CM is the intentional architecture of software development change-flow. According to this article http://bradapp.blogspot.com[..]/2007/05/software-cm-is-not-process.html Survey result of difference VCS within thoughtwork - http://martinfowler.com/bliki/VcsSurvey.html
(google search)
(amazon search)
Tue Dec 08 00:42:14 GMT 2009
From /weblog/software_engineering/project
Can everyone on the team write the aim of the project on a post-it note with a thick flip-chart marker? If not, then the end game is not clearly defined and universally understood. Come up to a colleague and say ‘can I ask a favour?’ just to see how they will react. If you get told off, the person is probably not very happy about the work. Richards advised building teams with “those who say can” , even when they are dealing with problems. Such people will improve collaboration and team spirit on the team. When a phase of project is officially done, ask yourself “is it safe enough to move on?”. If this question gives you a bad gut-feel, you aren’t done yet. How many of your projects ended with a serious project review? This is, according to Richards, crucial for organisational improvement, preventing repeated mistakes and sharing knowledge between teams. How would people on the team feel about the customer saying “I’ve changed my mind”. If the response is negative, the system isn’t as flexible as it should be. Ask someone for an update on a task and stay completely silent for 10 seconds – don’t do anything to provoke a response. If the other person is unsure or nervous about something, they will start spilling that out. If they too remain silent, things are going OK. Do you know how much time was spent on testing on your last project / iteration? If you can’t even estimate this, you aren’t collecting good actual measurements of the project. Collecting actual measurements is, according to Richards, crucial for getting to realistic work estimates. Pick up a document, turn it over and see what’s on the back. If you find diagrams, that suggest the need for clarity as people were drawing on it to explain things. http://gojko.net[..]chniques-to-test-how-a-project-is-going/
(google search)
(amazon search)
Sun Apr 05 17:25:04 GMT 2009
From /weblog/software_engineering/testing
This is probably one of the most common question in software testing interview. This problem was first introduced by Myers, who was one of the first person to treat Software Testing as a different subject all together. This test check your ability to think about generating test data in a given condition. Suppose your program accepts input as three sides of a triangle and gives output on what type of triangle is this i.e. Scalene (no sides are same), Isosceles (any two sides are same) or Equilateral (All the three sides are same). You have to come up with different test cases to test this program. You can write your test cases here, by giving side of the triangles and evaluate your test data. Once you are done with all the test cases you can think of, check your performance. If you want to restart your test anytime, just click on the restart test button. I have not covered all the possible test cases here as idea is to give you sufficient information to get started. http://www.testinggeek.com[..]er/154-triangle-test-in-software-testing
(google search)
(amazon search)
Fri Mar 06 14:36:44 GMT 2009
From /weblog/software_engineering
Automate build, test, and install processes. Automate dull, tedious, or repetitive work Automate to free time for creative, intellectual work. Never automate evolving processes. Do not automate in order to avoid human interaction. Prefer physical artifacts with coercive immediacy Software serves the team, never the reverse. http://agileinaflash.blogspot.com/2009/02/automating-tasks.html
(google search)
(amazon search)
|