Hey everyone! A friend of mine just passed an article which I thought I must share with everyone. Every time when you type the famous colon and parenthesis to express your emotion did you ever have the question that ‘ Where did this come from?’
I never had but it’s pretty amazing to find out about it. Check out the article.
Enjoy!
This post is dedicated to my fellow QA & test newbie-wannabe. I know I had a lot of trouble gathering materials to understand how to go about. In the world today the importance of quality assurance and testing in software development has grown and is much focused on. Not to mention, the search results on the keywords lead to several places for knowledge bundles but quite difficult to find the first step on climbing the ladder. I hope my experience can help some of you out there to start climbing. So here are some wonderful links that helped me understand the basics of testing and quality assurance ( also adding experience).
http://www.robdavispe.com/free
http://softwaretesting-faq.blogspot.com
It’s quite a lot to understand about and lots of terms to recall. You don’t have to memorize them all. 
Just refer to them whenever you need to look it up.
One great forum that you can always look into for different questions in different categories is http://www.sqaforums.com
If you have any trouble understanding a particular topic/term, you can always Google it up. Feel free to leave me comments if it has helped you or not.
Till then, enjoy climbing your first step !
Hi everyone. I’ ld like to share with all of you a prized possession of mine, my wonderful homeland. Some great people took the initiative to bring together a lovely picture. Hope you like and get to know more about it. Enjoy !
A Prize-winning video from Dhaka University team
Video made by ZANALA Bangladesh
I have read and heard in many forums, posts, discussions, blogs… etc that when an organization wants to adopt a new process to fit into the working culture, it doesn’t seem to come out the way expected or as the process says it results in. People wonder, tries to mend, work out the differences and ultimately in most cases what happens is it turns into some kind of mixed baloney. This causes frustration among employees, unsuccessful output, business loss etc. Very few find out the key that unlocks the problem and actually get it work. But then again why go through all of this only to understand that the new process may or may not meet your needs?
Before jumping into a new process that is the latest in the trend or that shows a good portfolio, every organization should first try to analyze their current process. Questions should be answered like: What are my current problems? How can I address each one with minimal cost and solve it to get the maximum output? etc. Once the problems are defined in a blank sheet of paper, they can be taken and thought individually to solve it. If the current process does not give the answers, then only another process can be thought of to implement.
But wait ! You cannot just declare right away that this new process ‘ABC’ looks good and seems to bring out good results; let’s try it ! It may just bring you more disaster. Before actually thinking of putting it on the floor, it is very crucial to understand that what is ABC all about.
There can be several more questions that can be asked to understand the process but it is just important to know how it works and then finally the big question can be answered: Does it meet my problems and needs and bring some percentage of output compared to the other processes?
If yes, go for it ! And then comes the harder part. To actually make the organizations’s resources adapt to it. Before adapting, it is important that the workforce understands the process enough to start making a change the right way and not mixed. To do this, workshops, hands-on experience of trial mode of practicing is necessary. It is not easy to adapt immediately but can happen within time if it is understood correctly in the beginning.
Ever recall when your doctor would say, ‘If you had brushed your teeth regularly, you wouldn’t have had a cavity.’ or ‘If you had taken a right diet, you wouldn’t have fallen sick.’ ? Hmm it always stinks to hear those kind of phrases right? But when you come to think about it, what if we did exactly those? I guess if we did, then we wouldn’t have to get a root canal or take those medications to get better and less pain. You see, it’s the same everywhere in nature, even in software development.
We tend to skip things beforehand and leave it to the guys to develop and when they are done, next thing you know, customer had totally the wrong expectation than what was done. Or, it would be something that would have so many bugs that couldn’t be fixed before deadline and project gets canceled/there is delay in payment. It’s pretty much a very common incident, right? Well, what if we tried to improve this situation. Realizations have occurred in time and measures were taken. Processes has been made for improvement and effectiveness. Roles have evolved to many types to play in significant activities within these different kinds of process. So where can a QA’s role take place and what kind of activities can be done?
A QA’s role doesn’t only mean involvement in test phase but in many other areas. After all, test is part of quality assurance. A QA can participate in ensuring quality in requirements analysis phase, design phase, during development, test and in release phase. The whole idea is to ensure quality. It might seem that too unrealistic for a QA to do all these things in all phases but QA can do significant activities and ensure the other activities are done. In that case QA roles can be divided in areas. By maintaining processes and checking, the workflow will be much more refined. But now let’s have a look on different areas where how a QA in a development team, within the development lifecycle can help prevent, rather than cure.
During the requirement gathering phase, there is communication involved between the client and the people who gather requirements. This may be in some case the account managers, the requirements manager, product manager etc. Requirements are taken based on what clients want to be developed. Sometimes how to be developed. Now there is three scenarios to be considered when taking in requirements which sometimes tends to me missed out.
A. New Functionality
B. Extension/Change in Functionality
C. Functionality that implicitly effects another
Now A is very easy to plug in itself but when it interconnects with C, there needs to be some kind of knowledge in between in order to understand the impact on the existing functionality. B is also applicable in the this case.
So how is this related to a QA being involved? When personnel who gathers requirements from the client, quite often, they do not have the functionality in mind completely or maybe the technical limitations, thus resulting to promises that cannot be delivered. In this case have a member from the development team ( could be a senior developer/ architect ) and a QA engineer who knows the functionality well enough can provide valuable input in helping derive meaningful and functional requirements. In addition, the QA can point out the different perspectives of quality in making the client aware of different consequences, thus helping the client understand better on what they actually want. By discussion, QA can help the client in deriving the acceptance criteria and use cases though with which the client can verify the end product. In summary, QA helps in ensuring that qualitative requirements are given.
I noticed that during the Design phase, it involves the techies only and assumed that other than them, others won’t be able to provide any information that could help or understand the architecture. I would say that in any phase, a second opinion is always helpful.
So how can a QA help giving a second opinion here? During the discussion in this phase goes very in-depth into units to understand the whole architecture to be built. Doing so, sometimes the overview is missed and many criteria that the client is looking for gets faded away. The QA can bring up the points time to time. Now you might say why do you need a QA to point out. You can have the things written and ensure the design supports it, which is absolutely correct. But experience says that getting to the technical parts, the flows, usability, performance, scalability on usage and things like these sometimes gets opt out. The QA can add support in bringing up the quality attributes into incorporating them in the design as well as add different points in client essence since being involved during the requirements phase. It’s very important for the builders to understand the nature of the client and their usage of the system. In summary, QA helps in ensuring that qualitative design considers the quality attributes is made.
We all follow the traditional way of developing and then testing the product delivered. And we all know that always we end up with bugs which makes it difficult for the testers and developers to come to an agreement in solving the bugs. How about we try to reduce these problems after the test phase? I’m sure things can be done ahead so that the cost in fixing those numerous amount of bugs later is much less. Here is where a QA can play the necessary role.
During the development the QA can do the following things and others if needed:
After everything is done, it’s time to to test the end product and finish it off by releasing it to the clients. Once again, with quality. During the test phase, the QA can assist the other testers to test the software. Also, the QA can help in making a successful release. During the release, when there is little to do, the QA still has work to do. Before the next cycle starts, the QA can prepare quality attributes that were missed in the previous release and make note to accomplish in the next one. This may include in preparing guidelines, checklists, process change etc.
So we pretty much covered on the activities of a QA in the development life cycle and the importance of it’s role within. In conclusion, QA helps in ensuring that ultimately a product with quality is made. So why wait and let something go wrong in the end and fight over fixing it? Why not try from the begin to refine things so we have less mess-sweeping up to do. Isn’t prevention better than cure? I’ll let you think and decide on that. Until then, happy QA-ing !
It’s funny how almost everywhere developers take the tester the troublemakers and vice-versa. Constantly there is a bitterness at some point in the game between these two roles. Wonder why? It’s the genre and responsibility of these two roles.
Naturally, developing something will have bugs. It will depend on the severity, type, and scope of the bug-fix to decide to work or leave out at the moment. At this point in time, situations can get nasty at the debates between these two roles. Of course tester will try to point out bugs after bugs in the test phase. After all its their responsibility.
While the bugs are there to fix, developers get frustrated at the count and even at the person as well. The understanding level between these two roles conflict not only in one place but in many areas. So how to make the relationship between these two good and understanding?
My experience says teamwork is the best solution. It’s the responsibility of both to ensure the ultimate product is working at its best. While the developers should ensure that there are no bugs out of what they develop, the tester’s should ensure that if there are bugs, those should be given, handled at the correct time and scope.
Please notice that I haven’t mentioned QA once but just tester. The reason is either a lone tester or a QA who tests, come in the test phase to do these work. Here is where the role as QA can help the developer to work better not to produce bugs. You see, a tester’s job is to crack down the product as soon as he/she gets. However a QA helps from the beginning to help the developer dudes to advise, point out areas where it’s error-prone. Thus resolving into less amount of bugs. Not only this helps in resolving issues with developers, considering the cost in business perspective is much less and customer is much less edgy than before. Who wouldn’t love to have something bug free right?
So my experience says, when you are a QA, the relationship between you and a developer becomes more friendly. As a team. Together, you are able to work together in finding defects beforehand which is appreciated always. Not only that, sitting together in a discussion of design, solutions, brings the developer to be aware of the different issues and areas to improve quality; thus taking the quality mind-set a step further.
When you are a tester finding the defects, it’s always good to share some tactics with the devs on how you test. Maybe this will help the devs to test better before delivering the product. But all of this works if everyone is cooperative enough to look in the actual target – to deliver with quality.
To support the phrase ‘Prevention is better than cure’ in SDLC, keep in touch with my upcoming articles.
Well, I think the previous article was actually created in 2006 when I merely learned the term.
But that’s where the nice surprise came to be. I was exposed to actually playing my role in SCRUM in the next job I had right after 4-6 months writing that article. Funny isn’t it.
Well, I assume we all know the old fasioned waterfall approach. 5 phases one by one and can’t return. Now reality is we have to go back an forth to redesign and implement and there have been so many other methods to make development more efficient in terms of money and cost.
SCRUM allows to go by small chunks like small iterations which is really productive and brings customer satisfaction because they are involved much closer to the work than the other processes.
Now I don’t want to go to details on what SCRUM is all about. Because I’m sure by now, lots of articles and research are published which you can just google and find out.
Many organizations are following it. I’ve practiced it myself so I’ld like to share my experiences and thoughts on SCRUM.
Interesting word isn’t it? I thought so. What’s more interesting about it is that it’s related to Rugby, the English football game. SCRUM, a management, enhancement and maintaince methodology for an existing system.
Well let’s see how it is really related to Rugby. Rugby is set by playing field which can be also termed as the environment for SCRUM and the rules for Rugby as the controls for SCRUM. The primary intention for Rugby is to move the ball forward as to the development process in SCRUM. Rugby evolved breaking the soccer rules to adapt to the environment where SCRUM is also has its environment variants. Rugby doesn’t end until the environment has complete control. Scrum doesn’t end until the business need, functionality, competion etc are all together to scrummage and make a good turnout.
Scrum has three phases. Pregame, where the planning and architectecture is defined. Game, where the actual development occurs and finally PostGame, where the preparation for realease occurs.
Scrum has numerous advantages and actually delivers the product on time and correctly with the joy of developers feeling satisfied and feeling they actually accomplished something. Isn’t that nice. Try it out. Maybe it will make your development process much much easier and productive. To know more about scrum try searching the net. If you are too lazy, here are a few links to help you.
