Recently, there are lots of discussion regarding to QA bottleneck in our release plan, or lack of communication between Dev and QA, i’d like to share my little experiences from my previous projects.
I’d like to divide the whole topic into two parts: Mindset changes and practical skills. Mindset changes are actually agile principles need be followed, and practical skills are actually what we can start to do. To be honest, my team is also far away from the ideal case, but we are trying to achieve more.

Mindset Change

1. development and testing is just a role (or a skill set), not a stable title

In all the traditional processes, QA and Dev are separately defined and clearly distinguished. For example, Dev maybe responsible for design and implementation, and QA is responsible for writing test scripts and running it. So, how dev designed the software, QA doesn’t want to know. And even there are hundreds of bugs, that’s the issue of QA. However, Agile doesn’t agree on it!

[Copy from another article, and changed a little]you’ll need to be flexible, work with others, pick up other skills. You’re not going to be testing or developing or whatever constantly. Just like a data person is not going to be doing data modeling constantly, there gonna be doing a little bit of data stuff, coding stuff, requirements stuff, some testing stuff, go back and do some data stuff and so on.

As we always say, work on the first priority user story before you start the next one. However, lot of people complained he/she didn’t finish his/her job, so i was blocked. That’s not True. Each of us should be really really flexible to execute any task, what ever unit testing or performance testing. When we break down the tasks, we should assign tasks based on your skill sets but not your current title.

2. software quality mainly is a result of development, not testing. At the same time, quality is the result of the team, not only the owner of user story

Please NOTE: i didn’t say it is a result of Dev or QA. I said, it is mainly a result of development, not testing. And as we discussion in the Mindeset change 1, development is not only the responsibility of developer. It is the responsibility of the thole team.

Agile(or our agile) always emphasizes one principles: the team should work as a team from beginning to the end. We are easily to understand develop activity will last from requirement analysis to release to production, but we always ignore the testing activity is the same case. Each of step of agile process, what ever user story definition or design or unit test, we all need the involvement of testing people.

And from technique perspective, White box testing is much easier to find root cause than black box testing. Actually, testing when developing (such as verifying data correctness, enough unit test) is a white box testing.

In summary, development decided the quality of software but not testing. we should start testing when starting developing.

3. quality need be ensured from the first minute of process, not the last minute before release

Why? During search development, i deeply realized one of common senses of software industry: The later the problem is found, the higher the cost. The root cause of a bug was found in production is not because lack of testing effort in stage/UAT/Production testing(To be honest, you will never get enough testing time if the original design/coding/implementation has issues), but because we found the issue too late.

Actually, this mindset change is another perspective of mindset change 2. In order to deliver high-quality software to production, we have to deliver high-quality software at the first minute. For example, does the requirement make sense and it will not impact performance? do we understand enough on design from coding perspective and testing perspective? do we start unit test before coding? do we go though the data correctness in database before accept the user story?

In summary, start testing as earlier as possible. And the testing don’t have to be done by another person (what ever developer or QA), it can be done by you also.

Practical Skills

In the first part, we described the major principles of the role of Dev/QA in agile process. But as we know, the idea things will not happen in one minute. The following are some experiences what search team are trying to archive these goals, and we can start from these steps

The skills need be mastered for a traditional QA

• Database knowledge & SQL
  We just found this is very very helpful to find issues during developing and testing. As a common service team, at the beginning, because we don’t have UI, we try to verify the result in database. And after that, we do think it can be common practice of other teams. It is even the most convenience way to verify the development.
  At the beginning, you just need to know the basic concepts of database, such as table, column, index, constraints, and also basic SQL statements. You can also ask help from developers.
• Design/Implementation Principles
  It is also very helpful practices. QA can discuss how it design and implementation with Dev and try to understand the concepts, such as connection, thread, asynchronization, EJB, JSP etc. You don’t have to understand very detailed coding, basic concepts already helps a lot.
• Code Review/Unit Test
  Actually, these skills are a little bit advanced skills, but it still can help you understand how the system works.
• Performance Tuning Knowledge
  It really help QA to understand the root cause of performance issue and how to identify the issue.

The skills need be mastered for a traditional developer

• Automation Testing Skills (Review automation testing scripts)
  Automation testing skills are very useful for a developers, and a very convenience way to verify your development results. And it help you understand how QA works.
• Performance Testing Skills
  I’d like repeat this point again and again: Performance testing and performance tuning is the two sides of one coin. Our experiences always show testing and tuning at the same time will bring more than double benefits. The turner should always sit together with tester to watch the result very very closely.
• A careful and patient heart
  As i always see, developer is never careful enough. Please remember, quality is the result of your codes, but not testing. You have the responsibility to make sure there are no stupid errors.

The above are my thoughts on this topic. I believe other teams or individuals also have good thoughts, please share it.