ACC is an approach that allows testers make more conscious decisions about distributing test effort. It also provides more visibility of the product and its testing to all stakeholders, and ensures better knowledge sharing within the team. Find more on the slides below.

ACC presentation for QA Club Kiev from Nikita Knysh

ACC: A Lightweight Approach to Risk-Based testing

ACC is an approach that allows testers make more conscious decisions about distributing test effort. It also provides more visibility of the product and its testing to all stakeholders, and ensures better knowledge sharing within the team. Find more on the slides below.

ACC presentation for QA Club Kiev from Nikita Knysh

Main question of testing: How to forecast quality of software?
(for devs, testers, clients, users)

- Analytic school (established when access to processor time was very limited).
Testing is a scientific, analytical work. SW is a logical artifact. Testing without test cases NOT possible. Lots of thinking. Quality can be measured with numbers! Creativity is not applied. Testing can be binarily Correct or Incorrect.
Weakness: Cannot guarantee that the software does the correct thing... Can only ensure that things that are done are done correctly.

- Standard school
Quality is conformance to standards. Standards and documentation needed to perform tests. Standardizing the standards! Testing is measuring of development process. Testing checks the product, not more.
Testing can be managed: predictability, metrics, repeatability, planning.
Testing only what is documented. Quality components guarantee quality system.
Weakness: Tests are OK, but there are still bus in SW!!!

- Quality school
Quality is what CUSTOMER dictates (that's documented and used as a guide to develop and test). There is no only one 'correct' standard.
Weakness: SW is done by docs, but it does NOT conform to wishes and expectetations.... Integration tests are used. Test cases still rule! 'Police control' after quality. Only testers know what 'it is ready' - and he is the main responsible. Devs make mistakes. "Testing is the most important part of the process" - testers of this school think ;).

- Agile school
Quality is customer's thinking / evaluation of product, not a standard or a document... Pelaple & working SW is more important than the docs. Let's sit together with customer and write SW! The same with test ;) Find bugs that important for customers!!!
'Police contolr' sucks! Everybody can test. Test automation & TDD rules! Automate everything!!! Prove that SW functions 'as expected'. User stories, DoD.
Still cannot quarantee quality of SW...

- Context-driven school
Everything is shit. Life is misery. The value of any practice depends on its context. There are good practices in a context, but there are no best practices.
The product is a solution. If the problem is not solved, the product oes NOT work!!!
Good SW testing is a challenging intellectual process.
Sometimes documentation is essential. Sometimes we need a test plan. Sometimes we DO NOT need testing...

Correct is what works HERE & NOW. Test what's important to customer!!!

The 5 Schools of software development (and test ;))

Main question of testing: How to forecast quality of software?
(for devs, testers, clients, users)

- Analytic school (established when access to processor time was very limited).
Testing is a scientific, analytical work. SW is a logical artifact. Testing without test cases NOT possible. Lots of thinking. Quality can be measured with numbers! Creativity is not applied. Testing can be binarily Correct or Incorrect.
Weakness: Cannot guarantee that the software does the correct thing... Can only ensure that things that are done are done correctly.

- Standard school
Quality is conformance to standards. Standards and documentation needed to perform tests. Standardizing the standards! Testing is measuring of development process. Testing checks the product, not more.
Testing can be managed: predictability, metrics, repeatability, planning.
Testing only what is documented. Quality components guarantee quality system.
Weakness: Tests are OK, but there are still bus in SW!!!

- Quality school
Quality is what CUSTOMER dictates (that's documented and used as a guide to develop and test). There is no only one 'correct' standard.
Weakness: SW is done by docs, but it does NOT conform to wishes and expectetations.... Integration tests are used. Test cases still rule! 'Police control' after quality. Only testers know what 'it is ready' - and he is the main responsible. Devs make mistakes. "Testing is the most important part of the process" - testers of this school think ;).

- Agile school
Quality is customer's thinking / evaluation of product, not a standard or a document... Pelaple & working SW is more important than the docs. Let's sit together with customer and write SW! The same with test ;) Find bugs that important for customers!!!
'Police contolr' sucks! Everybody can test. Test automation & TDD rules! Automate everything!!! Prove that SW functions 'as expected'. User stories, DoD.
Still cannot quarantee quality of SW...

- Context-driven school
Everything is shit. Life is misery. The value of any practice depends on its context. There are good practices in a context, but there are no best practices.
The product is a solution. If the problem is not solved, the product oes NOT work!!!
Good SW testing is a challenging intellectual process.
Sometimes documentation is essential. Sometimes we need a test plan. Sometimes we DO NOT need testing...

Correct is what works HERE & NOW. Test what's important to customer!!!

When you have a simple blog or a small site, it is enough to use just css and html to make your pages look good, but if you have a big service with thousands of css lines of code that would be not enought, as you need to provide more sections, pages and even have a few mirrors of your projgect.

In this case you have to provide more and more css codes, which can't be configurated or reused as much as you want. Sometimes you have to reuse some templates and change different files in order to make a minor change.

One of the helpers which i can offer for a big brogect or just for developers, who want to write smart and reusible code, is to use css preprocessors languages. Most of them offer such featuress, which can help to write smarter and create complexed web sites.

Here are basic opportunities of this languages, i'll use SASS language to show how it works

1 Variables 
$column-width: 60px;
.column {
   width: $column-width;
}
Output css:
.column {
  width:60px;
}

2 Inheritance

@mixin rounded-borders {

  border-radius:4px;;
}
.box {
@extend rounded-borders;
  color:#000;
}
Output css:
.box {
  border-radius:4px;
  color:#000;
}

3 Mixins
@mixin rounded-borders($deg) {
  border-radius:$deg
}
.box { 
  @include rounded-borders(10px) 
}
Output css:
.box {
  border-radius:10px;
}


There are top 3 tools which are offered: 

• Less - http://lesscss.org/ (nested blocks, logic, constants)
• Saas - http://sass-lang.com/ (same)
• Compass - http://compass-style.org/ (same + sprites management)

For Debitoor - it would be nice to have UI guidlines as constants in one place to customize ous css, use more structural and logical css with math functions, variables, autogenerated sprites, and other usefull options

CSS Preprocessors

When you have a simple blog or a small site, it is enough to use just css and html to make your pages look good, but if you have a big service with thousands of css lines of code that would be not enought, as you need to provide more sections, pages and even have a few mirrors of your projgect.

In this case you have to provide more and more css codes, which can't be configurated or reused as much as you want. Sometimes you have to reuse some templates and change different files in order to make a minor change.

One of the helpers which i can offer for a big brogect or just for developers, who want to write smart and reusible code, is to use css preprocessors languages. Most of them offer such featuress, which can help to write smarter and create complexed web sites.

Here are basic opportunities of this languages, i'll use SASS language to show how it works

1 Variables 
$column-width: 60px;
.column {
   width: $column-width;
}
Output css:
.column {
  width:60px;
}

2 Inheritance

@mixin rounded-borders {

  border-radius:4px;;
}
.box {
@extend rounded-borders;
  color:#000;
}
Output css:
.box {
  border-radius:4px;
  color:#000;
}

3 Mixins
@mixin rounded-borders($deg) {
  border-radius:$deg
}
.box { 
  @include rounded-borders(10px) 
}
Output css:
.box {
  border-radius:10px;
}


There are top 3 tools which are offered: 

• Less - http://lesscss.org/ (nested blocks, logic, constants)
• Saas - http://sass-lang.com/ (same)
• Compass - http://compass-style.org/ (same + sprites management)

For Debitoor - it would be nice to have UI guidlines as constants in one place to customize ous css, use more structural and logical css with math functions, variables, autogenerated sprites, and other usefull options

In agile development process, testing should be agile as well. But scripting approach (having TestCase base and executing test cases) is not very agile.

So, more flexible thing is exploratory testing. If your app. is a city...
Let's describe application districts:
# Financial - Features that would appear in marketing demo or sales demo.
# Historical - Legacy code. Known error-prone code (smthn like regression testing)
# Seedy - Undocumented features, vulnerable places w/ big negative impact to user
#Tourist district - Features commonly used by novice users but not experienced ones
etc.

In each district you could follow different tours for this district.
e.g.
in financial district, you could have Money tour - test features users buy the app. for (main functions), FedEx tour - follow your input thought the app. flows
in Tourist district, you'll enjoy Supermodel tour - check UI and usability, don't dig into features

And there are some other districts and tours.... so testing process in exploratory testing is based on taking some tours.

Further reading:
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design by James A. Whittaker 

p.s. Have a nice trip :)

Given by Nikita (nik)

Exploratory testing

In agile development process, testing should be agile as well. But scripting approach (having TestCase base and executing test cases) is not very agile.

So, more flexible thing is exploratory testing. If your app. is a city...
Let's describe application districts:
# Financial - Features that would appear in marketing demo or sales demo.
# Historical - Legacy code. Known error-prone code (smthn like regression testing)
# Seedy - Undocumented features, vulnerable places w/ big negative impact to user
#Tourist district - Features commonly used by novice users but not experienced ones
etc.

In each district you could follow different tours for this district.
e.g.
in financial district, you could have Money tour - test features users buy the app. for (main functions), FedEx tour - follow your input thought the app. flows
in Tourist district, you'll enjoy Supermodel tour - check UI and usability, don't dig into features

And there are some other districts and tours.... so testing process in exploratory testing is based on taking some tours.

Further reading:
Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design by James A. Whittaker 

p.s. Have a nice trip :)

Given by Nikita (nik)

Many web-apps don't load all the possible contents (scripts, styles etc) at the first time. They decrease the latency between "page asked" and "user can start do something". For now we load all the js/css (even if minified), but user can't do anything till it loaded

Buzz-words

• Big Pipe - how Facebook does it http://www.facebook.com/note.php?note_id=389414033919
• Script Dependency Management (each script knows his dependencies, load script when needed, async - many tools)
• CDN

We also touched the modern web-app structure and our problem of Public API coupled with HttpServer for serving html and statics. It means that for now our site and API always have same version, 1 fails - other fails, and it sucks. (abu)

Initiated by Eldar (edj)

Page Loading - Brainstorm

Many web-apps don't load all the possible contents (scripts, styles etc) at the first time. They decrease the latency between "page asked" and "user can start do something". For now we load all the js/css (even if minified), but user can't do anything till it loaded

Buzz-words

• Big Pipe - how Facebook does it http://www.facebook.com/note.php?note_id=389414033919
• Script Dependency Management (each script knows his dependencies, load script when needed, async - many tools)
• CDN

We also touched the modern web-app structure and our problem of Public API coupled with HttpServer for serving html and statics. It means that for now our site and API always have same version, 1 fails - other fails, and it sucks. (abu)

Initiated by Eldar (edj)

To run node on linux environment it have to be fail-over and easy to manage service. Topic shows a different ways to run and control node.js services

#0 just node myApp.js & (PROS: simple, CONS: no fail-over, dies w/ your session (bad if you work w/ remote linux server)

#1 run as linux daemon - buzz words: w/ package manager apt-get/yum/yast/zypper --install-> nohup, upstat, monit etc. OR write some $bash scripts and put them to /etc/init.d (PROS: continuous "console"-independent run but CONS: hard to implement; failover/self-recovery)

#2 use sweet tools

• forever (npm install and that's it) - continuous run, failover system; used in nodejitsu cloud
• supervisor -  continuous run, failover system, source changes detection and on-fly pick up
• nodemon -  same
• foreman -  same (used in heroku if not mistaken)

First three - "node-based", foreman - Ruby

Our choice - forever  - easy to install, easy to use :)

But we will try all tools from item #2, also maybe some hard-code core bash script. 

Test report would be provided in this blog

Given by Andrew aka Sly (aza)

forever node.js services

To run node on linux environment it have to be fail-over and easy to manage service. Topic shows a different ways to run and control node.js services

#0 just node myApp.js & (PROS: simple, CONS: no fail-over, dies w/ your session (bad if you work w/ remote linux server)

#1 run as linux daemon - buzz words: w/ package manager apt-get/yum/yast/zypper --install-> nohup, upstat, monit etc. OR write some $bash scripts and put them to /etc/init.d (PROS: continuous "console"-independent run but CONS: hard to implement; failover/self-recovery)

#2 use sweet tools

• forever (npm install and that's it) - continuous run, failover system; used in nodejitsu cloud
• supervisor -  continuous run, failover system, source changes detection and on-fly pick up
• nodemon -  same
• foreman -  same (used in heroku if not mistaken)

First three - "node-based", foreman - Ruby

Our choice - forever  - easy to install, easy to use :)

But we will try all tools from item #2, also maybe some hard-code core bash script. 

Test report would be provided in this blog

Given by Andrew aka Sly (aza)

Don't be lazy to adjust your layout for different devices a bit. Simple rules can help you a lot

• use media queries
• <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <!--[if lt IE 9]>
  <script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
  <![endif]-->
• avoid complex libraries with heavy dom and js (jq mobile).. at lease for nearest year.. at least for Androids :)
• in Debitoor: for tablets - don't set autofocus to inputs (to avoid half-screen keyboard), use native selects for touches etc (abu)

Info

http://playground.johanbrook.com/css/mediaquerydebug.html
http://mattkersley.com/responsive/
http://responsivepx.com/
http://habrahabr.ru/post/142120/ (big, RU)
http://webdesignerwall.com/tutorials/responsive-design-in-3-steps (quick start)
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/ (detailed)
http://frontender.com.ua/media-queries/ (nice dimension table)

Examples of x-device sites

http://themeforest.net/item/wp-flexishop-2-a-flexible-woocommerce-theme/full_screen_preview/2080989
http://themeforest.net/item/smartstart-wp-responsive-html5-theme/full_screen_preview/2067920

It's not a rocket science!

Given by Anton (ama)

Responsive Design

Don't be lazy to adjust your layout for different devices a bit. Simple rules can help you a lot

• use media queries
• <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <!--[if lt IE 9]>
  <script src="http://css3-mediaqueries-js.googlecode.com/svn/trunk/css3-mediaqueries.js"></script>
  <![endif]-->
• avoid complex libraries with heavy dom and js (jq mobile).. at lease for nearest year.. at least for Androids :)
• in Debitoor: for tablets - don't set autofocus to inputs (to avoid half-screen keyboard), use native selects for touches etc (abu)

Info

http://playground.johanbrook.com/css/mediaquerydebug.html
http://mattkersley.com/responsive/
http://responsivepx.com/
http://habrahabr.ru/post/142120/ (big, RU)
http://webdesignerwall.com/tutorials/responsive-design-in-3-steps (quick start)
http://coding.smashingmagazine.com/2011/01/12/guidelines-for-responsive-web-design/ (detailed)
http://frontender.com.ua/media-queries/ (nice dimension table)

Examples of x-device sites

http://themeforest.net/item/wp-flexishop-2-a-flexible-woocommerce-theme/full_screen_preview/2080989
http://themeforest.net/item/smartstart-wp-responsive-html5-theme/full_screen_preview/2067920

It's not a rocket science!

Given by Anton (ama)