Showing posts with label testing. Show all posts
Showing posts with label testing. Show all posts

September 10, 2010

On Lean And Agile (Gil Broza from Agile 2010 panel)

Gil Broza Article: Lean And Agile — Roommates, Married Or Twins?
Our panelists were all experienced Agilists who incorporate deep Lean thinking: Mary Poppendieck, Jim Shore, Alan Shalloway and Jean Tabaka.
....
Mary led with a quick definition: “Lean is delivering constantly increasing customer value for continually decreasing effort, leveraging energy and creativity”. The panelists all agreed that Agile is really a subset of Lean.
....
While Lean thinking can certainly improve the value flowing out an Agile team, its strong suit is in wider-scale application to the business and the whole value chain, “from concept to cash”. We have to pay attention to metrics that traditionally sat on the business side, as Agile lacks discipline around business methods. Teams must understand the business justification — and focus on delivering its promise.
Some people claim that “you can't improve what you can't measure”. But we manage things that we can't measure all the time. .... Lean will help us improve stuff even if it's not measurable.
Lean has us pay attention to throughput and value flow; it encourages having mechanisms for flow control. Agile's mechanism is the iteration ... Kanban's mechanism is the work-in-progress (WIP) limit
....
[the most common mistakes when implementing Lean?] Emphasizing practices over principles and culture; taking Scrum roles as gospel; not realizing the true nature of change (believing the only thing that needs to change are the programmers).
I was surprised by the panel's answers to the question, “What should teams be trained in?” Jean answered: “Reflection” — so the team can even take in the rest of the training, and apply continuous improvement. The other three all said, “Writing testable code!” They all emphasized the point of having great technical skill and writing acceptance-driven, defect-free code.

September 4, 2010

Defect Driven Testing: Your Ticket Out the Door at Five O'Clock

are you not doing TDD yet? start with DDT...

Defect Driven Testing: Your Ticket Out the Door at Five O'Clock:
Test automation is not a controversial topic in most circles. Even developers who don't write automated tests agree it's a great idea. They just don't have time to work on it very often.
....
DDT is a fairly simple concept. When you find a bug, add a test.

Why take this approach?

First, no one can dispute the need for the test. If an issue was found, then it had been missed earlier. Perhaps the developer missed it and QA spotted it. Maybe it slipped past everyone and it was reported by your customer. Whenever it's reported, it needs to be fixed in a way that will prevent it from reappearing.
....
DDT is a gradual approach.
....
Over time you'll find that DDT creates an extremely effective test suite that targets the most problematic parts of your code base. Run your defect driven tests inside of a continuous integration system and you'll find your code running more cleanly every day.

August 27, 2010

Dennis Stevens: We are Doing QA All Wrong

A few interesting things from an article by Dennis Stevens, very loosely quoted...

  • We Don’t Understand Quality Assurance
  • We Don’t Understand the Cost of Rework
    • Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.
  • the cost of setting up testing environments is much lower
  • Quality Assurance needs to be part of the development team and process. We need to change our thinking around this. So we need to integrate Quality Assurance very early in the process.
  • We have the Wrong Expectations
    • We Expect Perfection - Not Improved Value
    • We Expect Local Optimization - Not Flow
  • Enable value, flow, and ongoing improvement
Dennis Stevens » Blog Archive » We are Doing QA All Wrong 

From the comments:
  • One thing: No one can assure quality. Can I convince you to change the reference to “Quality Assistance?” (Jon Bach)
  • I prefer ‘testing’ and ‘tester’ to ‘quality assurance’ and ‘QA engineer’ or whatever. But these are nits. The message of Dennis’s post is the point – focus on value, improvement, delivering a better product. (Lisa Crispin)
  • I introduce myself to teams as the “public health nurse” for their project, and then subtly place ‘quality assistance’ in my email signature. (Adam Geras) 
  • testing is a complex, organic, cognitive activity, rather than a rote, bureaucratic, clerical one. (Michael Bolton)  

Blogged with the Flock Browser

May 26, 2010

TDD w/javascript using jsTestDriver and (f.ex) QUnit

JsTestDriver is seemingly yet another unit testing framework, and it stems from Google. I say seemingly, because the JsTestDriver guys has made some delicious improvements over the normal work flow which sets it apart from other unit testing frameworks for JavaScript so much it's not even funny to compare.

Having said that, JsTestDriver is (as the name implies) really more of a test runner. It ships a default assertion framework, however it doesn't offer all kinds of JavaScript specific assertions. Instead, JsTestDriver makes it fairly accomplish-able to use your current assertion framework of choice with JsTestDriver by providing a bridge. Last time I checked, both QUnit and YUI Test had functional bridges.
Test driven JavaScript done right / JavaScript - cjohansen.no

There's also an eclipse plugin.

 ff
Blogged with the Flock Browser

January 27, 2010

JsUnit - unit testing javascript

JsUnit is a Unit Testing framework for client-side (in-browser) JavaScript. It is essentially a port of JUnit to JavaScript.

JsUnit
Blogged with the Flock Browser

January 19, 2010

BugsVoice - turn bugs into opportunities

BugsVoice is ... serving friendly error pages and saving the exceptions and feedbacks on your account.

So if you get a trapped exception in your application (or in your web server), this will print out the script copied from your BugsVoice account, display the friendly error page to your customers, and collect their eventual feedback. All this will be saved in your account, and you can access any time to inspect the bug, feedback the customer etc. :-) .
BugsVoice - turn bugs into opportunities
Blogged with the Flock Browser

January 18, 2010

powermock

PowerMock is a framework that extend other mock libraries
....
By using a custom classloader no changes need to be done to the IDE or continuous integration servers which simplifies adoption.
....
PowerMock aims to extend the existing API's with a small number of methods and annotations to enable the extra features. Currently PowerMock supports EasyMock and Mockito.
powermock - Project Hosting on Google Code
Blogged with the Flock Browser

June 24, 2009

VirtualBox

VirtualBox is a powerful x86 virtualization product for enterprise as well as home use. Not only is VirtualBox an extremely feature rich, high performance product for enterprise customers, it is also the only professional solution that is freely available as Open Source Software
VirtualBox

spesielt interessant for ei dedikert test-/ CI-maskin (kontinuerleg integrasjon), der det kan køyrast ei eiga VM for kvar kunde-konfigurasjon som er under test/CI, kopiert frå ein felles mal med linux, postgresql og jboss. dvs at me treng berre å helda ved like ein mal...
Blogged with the Flock Browser

June 2, 2009

CubicTest

CubicTest is a graphical Eclipse plug-in for writing Selenium and Watir tests. It makes tests faster and easier to write, and provides abstractions to make tests more robust and reusable.
CubicTest
Blogged with the Flock Browser

September 11, 2008

automatic testing - challenges

"practice of testing .... turned our art into engineering, introduced process-models, come up with best-practices, and developed tools ..."
Google Testing Blog: Automating tests vs. test-automation

downsides, problemer:
  • "Scripting your manual tests this way takes far longer than just executing them manually.
  • The UI is one of the least stable interfaces of any system, so we can start automating quite late in the development phase.
  • Maintenance of the tests takes a significant amount of time.
  • Execution is slow, and sometimes cumbersome.
  • Tests become flaky.
  • Tests break for the wrong reasons."
men: "advantages of automation still outweigh the cost. .... accept some of these problems as 'the price of automation'"

og der er workarounds:
  • "It takes long to automate a test—Well, let's automate only tests that are important, and will be executed again and again in regression testing.
  • Execution might be slow, but it is still faster than manual testing.
  • Tests cannot break for the wrong reason—When they break we found a bug."
nokre poeng frå artikkelen (mi utheving):

"...a system exposes different interfaces to the environment—e.g., the user-interface, an interface between front-end and back-end, an interface to a data-store, and interfaces to other systems—it is obvious that we need to look at each and every interface and test it. ... also avoid testing the functionality in too many different places."

"...how this system looks inside.
  • Is there a database? If so, the verification should probably not be performed against the UI but against the database.
  • Do we need to interface with a supplier? If so, how should this interaction look?
  • Is the same functionality available via an API? If so, it should be tested through the API, and the UI should just be checked to interact with the API correctly."
"Applying these simple questions will allow us to:
  • write many more tests through the API, e.g., to cover many boundary conditions, ....
  • start earlier with testing the system, as we can test each interface when it becomes 'quasi-stable',
  • makes maintenance of tests and debugging easier, as the tests break closer to the source of the problem, ...."
"To summarize, I figured out that a successful automation project needs:
  • to take the internal details and exposed interface of the system under test into account,
  • to have many fast tests for each interface (including the UI),
  • to verify the functionality at the lowest possible level,
  • to have a set of end-to-end tests,
  • to start at the same time as development,
  • to overcome traditional boundaries between development and testing (spatial, organizational and process boundaries), and
  • to use the same tools as the development team."


August 12, 2008

It's common sense, stupid: Tips to Write a Good Bug Report

Writing is easy, but writing clearly is hard.
It's common sense, stupid: Tips to Write a Good Bug Report

Do's

1. Clear title - the developer should be able to grasp the essence of the bug report from the title alone.

2. One bug per report - no more, no less. reason: confusion, duplication, may be overlooked.

3. Minimum, quantifiable steps to reproduce the problem

4. Expected and observed results

5. which version of the software

6. references - like related issues

7. Pictures-- A picture is worth a thousand words!

Dont's

1. Don't write generic titles
2.
Don't just chat - document personal communications, so that the knowledge won't be lost
3. Don't assume that the developers can read your mind


November 8, 2007

Enkle screenshots i firefox

https://addons.mozilla.org/en-US/firefox/addon/5648

Ser temmelig pen ut. Mye mindre smertefullt å illustrere bugs.

(Inge via epost)

April 16, 2007

skjermbilete til bugs

mi fyrste anbefaling: ifranview

IrfanView - Official Homepage - one of the most popular viewers worldwide
IrfanView is a very fast, small, compact and innovative FREEWARE ... graphic viewer .... It is trying to be simple for beginners and powerful for professionals.
enkel oppskrift:
  • "print screen" (ev m/alt-tast) ved interessant skjermbilete,
  • opna ifranview,
  • ctrl-v (lim inn),
  • marker firkant rundt relevant område,
  • ctrl-y (crop),
  • s (save),
  • bruk i bug-verktøy "of choice"
eit anna verktøy som ser interessant ut: Screenshot Captor
Screenshot Captor is a program for taking screenshots on your computer. ....
  • Optimized for taking lots of screenshots with minimal intervention.
  • Smart autonaming of files, and ability to embed textual comments in files.

May 9, 2006

Continuous Integration

ikkje heilt ferdig med artikkelen, men i fylgjande avsnitt jobbar me heilt oppskriftsmessig, heilt til siste biten (det som kjem etter "my commit"), jf sitat nedanfor.
kort sagt: anbefalt med jamnleg automatisk bygging/ deploying for ulike kundar...

Continuous Integration: "However my commit doesn't finish my work. At this point we build again, but this time on an integration machine based on the mainline code. Only when this build succeeds can we say that my changes are done. There is always a chance that I missed something on my machine and the repository wasn't properly updated. Only when my committed changes build successfully on the integration is my job done. This integration build can be executed manually by me, or done automatically by CruiseControl."
....
"Less time is spent trying to find bugs because they show up quickly."