Agile testing

Agile testing

If You want to start with agile testing on Your project – firstly You need to forget that You’re only QA/QC. In agile testing You are agile software development engineer which is involved in development processes from test perspective.
It’s very interesting – what are real responsibilities of agile tester?
Let’s think about usual responsibilities of testers on the project. Tester need to write test documentation, tester need to test application and report a bugs, tester need to prepare release documentation about defects, test process, etc.

But maybe it’s possible to avoid unwanted bugs? No – it’s impossible. But possible to reduce amount of the bugs. How to do it?
First of all – tester need start to think not only on the level of acceptance user. Try to think on unit level of application, on component and integration level. Try to think about behaviour of relationship between component.

Yes, I’m talking about TDD and BDD approaches. For this You need to know another agile testing approaches which are very useful and are required.

Test pyramid


As a agile tester You need to make test coverage on Your test application like it’s on image above. If You want to avoid long time verification during GUI testing, UAP testing – try to cover Your application by tests on unit and integration levels. This approach will help You to avoid the verification of a lot of cases on GUI level. This is ideal model.

Another approaches – Agile testing Quadrants (image is taken from


Important to divide You project for 4 Quadrants. Each of these quadrants covers another side of the project. You need to remember about importance of Automation testing on the project. Automation testing – it’s not only coverage of application on GUI level. It’s coverage by Unit tests, Behaviour tests.
Each of these quadrants also has priority. I will try to explain more about Agile testing quadrants in the next articles.

Let’s go next.


What is TDD (Test-driven development) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards (From Wikipedia).


It’s mean that agile tester should really know development process.
What the tools are useful – all the unit-test framework. (JUnit, NUnit, TestNG etc.). It’s depend on platform where You’re working.

But what if You need to join all the created functions? You need to create some real behaviour scenarios and test it too. You need to think from business perspective and from test perspective on development level.
In this case it’s time to bethink about ATDD.
ATDD (Acceptance test-driven development) 
is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as Specification by Example, Behaviour Driven Development (BDD), Example-Driven Development (EDD), and Story Test-Driven Development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language. ATDD is closely related to Test-Driven Development[TDD]. It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding. (from Wikipedia)

The most popular practices is BDD. You can describe Your test story in human-readable text or html file and implement it in the code. This is very useful if You want to collect You test documentation and code in one place. It’s called Living documentation.
The most popular tools are JBehave, Cucumber, Concordion.

So, as You see – agile tester it’s a bit different tester from non-agile, because agile tester need to be able with developers on the same code. Don’t scare to use these approaches and practices on Your project. You will see benefits after some times. It will help to save the time of test execution.

Best regards,


Unit testing as part of QA’s responsibility

Hi folks!
This article is about unit testing in responsibility of QA engineer. As we know – exists different type of testing: unit (module), component, integration etc. Generally  – coverage of code by unit tests is developer’s responsibility. Because for developer it’s easy to do. He knows how some method was implemented and what need to verify here. But in this case a lot different edge-cases could be missed. That’s why now is existing some tendency that test engineers should covers the code by unit tests. Here are some benefits: test engineer will be read each line of the code and can find some gap where not implemented exception or something like this. Test engineer knows a different technique of testing, like boundary values etc. Test engineer will think how to implement DDT in TDD.
Ok, let’s think that You are assigned to the project and You need to do something like this. How to start and what You need to know.

  1. What framework for Unit testing is used. Is it JUnit or TestNG for JAVA.  NUnit or MSTest for C#?
  2. You need to think how much data You need to cover some functionality. You need to know this for choosing format of data saving. If it should be a lot of data for 1 test – better to save it in some *.xsl or *.csv files. If it should be a data for a lot of different tests – better to collect everything in *.xml or json format. Much easier to read file for people (from my perspective)
  3. You can divide the test classes by some logic or better – it’s to have separate test classes for each of classes in application.
  4. As QA – You need to find all the gaps in the code. You need to find where can happens unexpected exceptions and need to cover it.
  5. Remember – that unit test should cover only one unit, not 1 big method, which contains calls to a lot of small methods.
  6. Cover by unit tests everything. Even if You are thinking that here can not be error. Better to cover everything than catch unexpected error on production.
  7. Don’t scare to ask developers if You don’t understand something.

Here are a few useful link which You can read to understand, what You need to do. EasyTest, TestNG (DataProvider).

Thanks to all! And have a good testing!

Way to QA

Way to QA

Nowadays a lot of people believe that QA (tester, test engineer) – the lightest engineering position in the IT sector. A few years ago on this post really was quite easy to get. It was enough to know English at a level below the average, to understand the PC at the level of average user .. well, actually that’s all. Of course, there were projects where the requirements were much higher, depending on the project. Over the years, the IT market is overflowed by “engineers” who can communicate in English at the secondary level and know how to go to “regedit”. And now to become on the position QA / QC – need to know much more and need to expand their horizon of knowledge.

         So, what you need to know / be able to become a test engineer at the present time. 

  • Foreign languages. Often test engineers need to serve as project manager. As you know, outsourcing it’s mainly foreign customers, who will be very happy if somebody from the teams which will serve their request, be able to communicate in their own language. Of course, English is №1 list of required languages, as it is the language of all meetings, discussions, etc.
  • Knowledge of basic (but preferably all) concepts ISTQB. Candidate for the position of QA Engineer obliged to understand such concepts as Test Design, Test Case Design Technique, Test Plan, Test Case, Test Coverage, QA, QC, Quality, Bug and all artifacts that relate Test Case or Bug. The candidate should also understand why knowledge of these concepts are important to the project. After QA – this is the man on the project, who decides whether application is ready to go to the end user or not.
  • It is necessary knowledge and skills то use systems such as Test Tracking System, Bug Tracking System (this is not a specific application names. Examples of these programs can be Jira, TestLink, Bugzilla, HP Quality center, etc.)
  • Not do without the knowledge management operating systems. And not only the family of Windows, but * NIX systems too. Test engineer will need to customize his own test environment not only once. As a rule, none of the team does not want to do it, so expect a big help is not necessary. Better to be able to adjust everything.
  • Recently on QA engineers also “voluntarily requested” basic knowledge in automation testing as simple cover car test application, rather than hire 100500 testers. And this, of course, need to have a basic concept in OOP and additional platforms that will be used for testing. Described in more detail in another article here.
  • Also test engineer is required to be able to analyze problem areas found in the application and in the software development process.
  • And most importantly – a desire to be a test engineer not because of good salary but because the work is really like. Because if testers do not like his work, then do not look for high quality software.

So, here described such a requirement for genuine Software Test Engineer, whose companies wish to employ and do not want to let go. To acquire such knowledge – takes about 3-4 months very hard work on yourself.
Thanks to all who read this article. Stay tuned, write comments or private mails, I will try to answer all.