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.
posted on 2008-12-10 13:39
Justin Chen 阅读(1411)
评论(1) 编辑 收藏 所属分类:
Agile