Agile Buddha

Demystifying Agile, Getting to its Core

Pair Testing

Agile Testing is achieving quality in everything

by 1 Comment

We know “Testing As An Activity” is important, and why we should all test. The old axiom that “Testers Test and Programmers Code” is so outdated now and everyone needs to change. Testers are the testing experts in a team, and can help enable the whole team to own quality but they are certainly not the only one’s who should be testing. Like, developers need to contribute towards testing by unit testing their code and also pair testing to minimize defects and minimize test – defect-fix cycle.

Agil-Testing-Quadrants

Testing in agile, addresses the processes that produce software and also products of those processes. Hence I ask my teams to not just focus on validating software after development, but also check processes that produce software like, quality of stories, requirement/impact analysis, acceptance criteria(using behavior-driven-development to address “3 amigos problem), and more.

Take a look at our agile testing workshop which is a detailed 2 day course which focusses on test automation strategies, lean approach to defect prevention, various tools and techniques to automate, BDD(behavior-driven-development) and how to use various frameworks – Linear Scripting, Test Library Architecture, Data-Driven Testing, Keyword/Table-Driven and Hybrid automation frameworks.

Dev Box Testing : Reduce Your Bug Life Cycle

by 13 Comments

The idea of dev-box testing is simple but very effective. Let’s take an example of a development cycle:
  1. Developer implements the functionality along with unit and integration tests and when she’s satisfied she commits the source code in the source code repository like svn or git.
  2. Continuous Integration (CI) gets triggered by source code commit and CI tool like Jenkins performs the automated build which results in code compilation and execution of the test cases (unit, integration and automated functional tests).
  3. After multiple builds when developer thinks that functionality is ready for functional testing, she asks the tester to take a specific build and test.
  4. Tester starts testing. If tester finds bugs in the functionality, she informs the developer about the problem and developer again begins from step 1.
  5. If everything is good, tester moves the user-story into DONE state.

Working through step 1-3 takes a lot of time and if testers has to move the story again in development, it results in a lot of time-waste and frustration.

How about this?

As developer sees everything working on his machine, he asks tester to test the functionality on his machine. While testing on dev-machine if everything works, only then developer commits the code which eventually triggers the build and auto-deployment. On the committed code available in testing environment tester performs further exploratory tests. Otherwise developer continue to fix the issues on his machine. This way, a lot of valuable time is saved.