|
Re: Announcement - Roundtable Meeting [Saturday - 16th June 2007]
Hello everybody,
First of all, I would like to thank everybody for including us (leaving abroad) in the roundtable by conference call. I wanted to join some of the discussion, but the voice quality was sometimes too poor at my end and was breaking up a lot that would've been inappropriate for proper conversation and cause unnecessary delay as time was limited. Instead, I will just share my thoughts and questions here and we can discuss here if interested.
1. First of all, I think all requirements needs to be documented properly. Some of the companies did say that they send back the requirement analysis and design back to the client for review. I believe this is very important because this removes any blurryness about what the customer wants, the developers needs to code and the testers needs to test. But testing should not be limited to the test strategy (derived from the design document after the client has accepted it). As a software can always have endless bugs, the test strategy will always miss endless tests to plug those holes. But the test team must first finish testing according to the test strategy document before going into deeper mudholes.
2. A lot of us are concerned about the conflict between the testers and developers. It is true, it is natural and it can have a very very positive effect on the product and the production process(testing/development/design) if taken positively. What both the developer and tester needs to understand is, a problem can be a bug or a limitation. And its not always the developers fault that something is broken in the product or the testers fault that the tester is testing something that is invalid, it can be a glitch from the design too or even a glitch in the requirement. I believe each team lead and manager can have a session with all the developers and teseters in the same room and discuss more about this. Someone (i think from ASHA) said they restrict the discussion between a dev and a test guy through a system/software. I agree with this idea. I also believe it is "extremely" important that managers/team leads/project focals monitor and participate in this system/software based discussion continuously. This probably will ensure that both the developer and the test guy will be "nice" to each other because the "bosses" are watching. And both parties needs to be able to accept "constructive criticism" in a positive way. I believe this argument is important because these kind of arguments sometimes opens up the doors about a limitation or flaw in the design/test process (no design or process is flawless). This process also keeps everybody informed about the bugs and their severities so they can weight a bug and have it fixed before release. We can gain knowledge from these arguments and plan a better way for the next design document or test process. As some people said in the meeting, this is just an opinion, not a conclusion.
3. Some one said in the meeting that the client keeps on introducing new requirements during the development lifetime. Yes, the world changes and thats why we have versions :) (just joking ... no personal attack). I think the best approach for this situation is to maintain design documents for upcoming version. The new feature can be implemented and tested in the next version of the software. The client and company should come into an understanding about the design process of each version.
4. About evaluation of a tester, it really is a difficult job. But point 2 can help here. If the team leads/managers monitor the bug reports and discussions about the bug, they will know how much effort the tester has put into the problem. A tester can just say that we have a problem in function x or provide detailed information about the system and enviorment settings before calling function x by minimizing the testcase to a bare minimum and possibly a step by step instruction/script to reproduce the whole problem. The later will prove that the tester has invested time and effort in finding this bug and the bug report has clearly detailed instructions to reproduce the whole problem in a snap so that the developers need not spend much time to get to the problem and concentrate on development rather than testing. Also the tester needs to search for similar problems that was posted in the past for the developer's reference. Peer review is also a very effective way as some has mentioned it in the meeting. But rest assure that big companies like Microsoft or IBM does have similar problems. The more communication there is between the tester and the whole team (including the development), managers/team leads can have more idea about the contribution of a tester to the team. Personally, I do believe in number of bugs a tester has found, but I would say at least 30% of the process should look at the effort the tester put in to make a clear and precise bug report.
5. At some point in the meeting, someone mentioned about bugs can be limitations of the current technology. I would like to add that if youre using a bug tracking software, it is a very good idea to put these limitations under a separate component (maybe "limitation") so that when discussing the next version's design, these can be brought up and plugged. For the current work I do, I have seen a lot of these kind of limitations slip through several versions of a product.
6. One thing I would like to emphasis on is testcase review. Product changes in time and so does the test process. We need to go back and review our old testcases as new versions of the product come out. This can be a low priority work, but certainly should not be ignored because a new feature or modified feature might need new added testing on top of the current one.
7. During the last minutes of the meeting, some people talked about having the test team be the gatekeeper of a product release. Personally, I would say no. I think its better to have a release management perform this job. The test team can provide a report to release management that x% of the testcases passed, y% are limitations and z% are actual bugs still present in the product. The release management can then verify the limitations and bugs of the product and make a decision if it is a stop-ship or not and push development to fix some important bugs.
Sorry for the long note about the meeting. I am still a novice in this field compared to most of you and I might be mistaken in some of these points. Please feel free to comment/discuss on them. Again, thanks for the conference call feature. Looking forward to the next meeting.
- Tareq Ahmed Siraj
C/C++ Compiler Test and Validation, IBM Canada.
" Success is doing ordinary things extraordinarily well. - Jim Rohn"
--- In sqa_bangladesh@yahoogroups.com, "Tahmid Munaz" <munaz23@...> wrote:
>
> Hello everyone,
>
> We would like to announce our next "RoundTable Meeting" on Saturday,
> June 16, 2007. You are welcome to join to our Roundtable meeting through
> the SkypeCast at that time.
>
> Date and Time: Saturday, June 16, 2007 [4:00pm to 6:00pm]
>
> Topic: "State of Software Test Teams in BD"
>
> Participants: 15 to 20 (Invited guest) + number of persons through
> SKypeCast
>
> SKypeCast URL:
> https://skypecasts.skype.com/skypecasts/skypecast/detailed.html?id_talk=\
> 3000526&hash=e327899f81a5e8e693f3
> <https://skypecasts.skype.com/skypecasts/skypecast/detailed.html?id_talk\
> =3000526&hash=e327899f81a5e8e693f3>
>
> Agenda of Discussion:
> Selected Senior Test Engineers and Test Team Leads will come together to
> share their experiences in software testing. Discussions will include
> tester evaluation process, training, hiring, useful testing tools,
> overcoming issues with the development team etc. We will discuss what
> works and what does not work, based on our experience.
>
> Technical Support:
> Please feel free to add my Yahoo IM ID: munaz23 [ munaz23(at)yahoo.com ]
> to keep updated of the round table session in case of any technical
> difficulties for the SkypeCast joining or disconnection.
>
> We hope for your valuable contribution in this event.
>
> Thanks,
> Tahmid Munaz
>
> On Behalf of
> SQABD Management
> www.sqabd.com
> cell: +8801819957135
>
|
Having problems with message search?
Fill out this form to ensure your group is one of the first to be migrated to the new message search system.
Offline 
Send Email
