After much hard work, a new version of the very best java-based, open-source test automation framework is now available for download here:
https://sourceforge.net/projects/sqaevangelist/
Use it for your rapid, easy, painless test automation of mobile and web UI applications for your product or company.
Saturday, March 5, 2016
Friday, November 27, 2015
The 3 most important questions a SQA candidate can ask a potential employer during an interview
You are a talented and ambitious SQA professional, and you want to make a career move.
So you got a call from the really cool company that you submitted a resume to, or perhaps they found you on LinkedIn and contacted you via InMail.
Then you have a good phone screen call from the hiring manager or recruiter.
Now, it's time for an onsite interview for a few rounds of face-to-face interviews with your potential new co-workers.
You have a game plan to impress them: Look good, polished, wear that snazzy business suit that cost you $800 at Hugo Boss, and smile and be attentive to every question and try to get along with every person on the interview schedule.
Ok, great. But more is at stake here: an important career move for you, for a variety of reasons.
It's even more important for the potential employer to impress you as much as you want to impress them.
Being a SQA professional is a tough gig. SQA is almost always a neglected part of the engineering team. SQA is almost always fighting for respect and recognition as an important contributor to a great product offering. SQA team is often regarded and thought of as less talented than the development team.
You won't find a perfect team or a perfect job, but you might find a really good one, and certainly one that you can enjoy working on and be a productive and important member of. So I recommend asking 3 crucial questions to the team during our onsite interview, most especially to the hiring manager:
1) Who's responsible for quality?
The answer you are looking for is: everyone.
This answer reveals a greater consciousness that delivering quality is a requirement from each member of the team. From the receptionist, executive assistant, janitor, sales, product management, development and SQA resources. It's a team win or lose.
2) What software development process do you use and how has it been improved over the past year?
The answer you are looking for: probably something like Agile development where it de-emphasizes multi-tasking, encourages closer collaboration between product, sales, development, and QA teams, uses Retrospectives for team discussion on improvement. The main thing you are looking for is all parts of the team taking responsibility for both good and bad things that happen.
3) A critical bug is found by a customer. Where do you start investigation how the bug got into a production environment?
The answer you don't want to hear: SQA missed this and is at fault.
There are several factors that are possible that might precede a critical customer-facing or production bug: Compressed/inadequate development schedules, lack of unit testing by development team, requirement/use case not revealed by product management team, not enough testing time, late or last minute code changes. And, in some cases, SQA didn't test that part of the product or use case.
The point here is that you don't want the default scapegoat to be the SQA team every time a bug is missed in the testing activities. In some cases, yes, QA for whatever reason is the entity at fault. But usually, many other factors contribute to bugs, which the SQA team has very little control over.
Asking these types of questions will provide you with a lot of great information about if the mindset and practices of the potential employer, and if team aligns with your desired work environment for a SQA resource. So make sure to ask these and many other questions to be sure you are fully informed on the cool opportunity.
So you got a call from the really cool company that you submitted a resume to, or perhaps they found you on LinkedIn and contacted you via InMail.
Then you have a good phone screen call from the hiring manager or recruiter.
Now, it's time for an onsite interview for a few rounds of face-to-face interviews with your potential new co-workers.
You have a game plan to impress them: Look good, polished, wear that snazzy business suit that cost you $800 at Hugo Boss, and smile and be attentive to every question and try to get along with every person on the interview schedule.
Ok, great. But more is at stake here: an important career move for you, for a variety of reasons.
It's even more important for the potential employer to impress you as much as you want to impress them.
Being a SQA professional is a tough gig. SQA is almost always a neglected part of the engineering team. SQA is almost always fighting for respect and recognition as an important contributor to a great product offering. SQA team is often regarded and thought of as less talented than the development team.
You won't find a perfect team or a perfect job, but you might find a really good one, and certainly one that you can enjoy working on and be a productive and important member of. So I recommend asking 3 crucial questions to the team during our onsite interview, most especially to the hiring manager:
1) Who's responsible for quality?
The answer you are looking for is: everyone.
This answer reveals a greater consciousness that delivering quality is a requirement from each member of the team. From the receptionist, executive assistant, janitor, sales, product management, development and SQA resources. It's a team win or lose.
2) What software development process do you use and how has it been improved over the past year?
The answer you are looking for: probably something like Agile development where it de-emphasizes multi-tasking, encourages closer collaboration between product, sales, development, and QA teams, uses Retrospectives for team discussion on improvement. The main thing you are looking for is all parts of the team taking responsibility for both good and bad things that happen.
3) A critical bug is found by a customer. Where do you start investigation how the bug got into a production environment?
The answer you don't want to hear: SQA missed this and is at fault.
There are several factors that are possible that might precede a critical customer-facing or production bug: Compressed/inadequate development schedules, lack of unit testing by development team, requirement/use case not revealed by product management team, not enough testing time, late or last minute code changes. And, in some cases, SQA didn't test that part of the product or use case.
The point here is that you don't want the default scapegoat to be the SQA team every time a bug is missed in the testing activities. In some cases, yes, QA for whatever reason is the entity at fault. But usually, many other factors contribute to bugs, which the SQA team has very little control over.
Asking these types of questions will provide you with a lot of great information about if the mindset and practices of the potential employer, and if team aligns with your desired work environment for a SQA resource. So make sure to ask these and many other questions to be sure you are fully informed on the cool opportunity.
Wednesday, November 18, 2015
The success rate percentage predictors of training a manual QA person to become an automated tester
Since 2010, every job I have had has included one task that is particularly difficult to achieve: train and convert a mostly manual QA tester (or team) to be an automated tester.
Most timeframes include 3-6 months to accomplish this task.
I have never had a 100% conversion rate. I have never had a 50% conversion rate. The average is most likely hovering around 30-40%.
Why?
Well, several factors determine how successful a manual QA person transitions to be an automated tester. And by knowing little bit of data beforehand, I can almost accurately predict which people can successfully learn test automation skills and write excellent test automation to augment their manual tests:
1) Software education background and coding experience - this one is the most relevant in predicting the outcome of the QA person making the transition. This contributes 60% to successful chance of the conversion.
2) Familiarity with one or more of the testing technologies chosen for implementation - for example, SQAEvangelist uses a stack including Ant, JUnit, TestNG, Selenium/WebDriver, and Java. This contributes 15% successful chance of conversion.
3) Ambition - believe it or not, this attribute contributes a lot. 15%.
4) Work ethic - good intentions and great work habits don't help to succeed much - 5%.
5) Training - someone spend 1:1 time and helps the tester understand how to do it and even goes through examples. 5%.
Remember that these numbers do not guarantee failure or success or each person making the transition. It's a hard and impossible road for some QA people.
People with attributes 1 and 2 are nearly a lock to make quick contributions to the automated testing effort with a few days.
I have found that any person with attributes 1 and 3 are almost certain to become a good automated tester and can almost be efficient and make significant contributions.
So before you challenge the team to learn automated testing, consider these factors before making a final decision. Analyze the team and predict it's chances of success beforehand.
It may be easier to hire/create an automated testing team to automate and just let the manual testers stay manual testers.
Most timeframes include 3-6 months to accomplish this task.
I have never had a 100% conversion rate. I have never had a 50% conversion rate. The average is most likely hovering around 30-40%.
Why?
Well, several factors determine how successful a manual QA person transitions to be an automated tester. And by knowing little bit of data beforehand, I can almost accurately predict which people can successfully learn test automation skills and write excellent test automation to augment their manual tests:
1) Software education background and coding experience - this one is the most relevant in predicting the outcome of the QA person making the transition. This contributes 60% to successful chance of the conversion.
2) Familiarity with one or more of the testing technologies chosen for implementation - for example, SQAEvangelist uses a stack including Ant, JUnit, TestNG, Selenium/WebDriver, and Java. This contributes 15% successful chance of conversion.
3) Ambition - believe it or not, this attribute contributes a lot. 15%.
4) Work ethic - good intentions and great work habits don't help to succeed much - 5%.
5) Training - someone spend 1:1 time and helps the tester understand how to do it and even goes through examples. 5%.
Remember that these numbers do not guarantee failure or success or each person making the transition. It's a hard and impossible road for some QA people.
People with attributes 1 and 2 are nearly a lock to make quick contributions to the automated testing effort with a few days.
I have found that any person with attributes 1 and 3 are almost certain to become a good automated tester and can almost be efficient and make significant contributions.
So before you challenge the team to learn automated testing, consider these factors before making a final decision. Analyze the team and predict it's chances of success beforehand.
It may be easier to hire/create an automated testing team to automate and just let the manual testers stay manual testers.
Thursday, September 25, 2014
Build a great QA team, and then empower them to make product release decisions
http://www.cnet.com/news/apple-releases-ios-8-0-1-a-week-after-ios-8-launch/
One thing very clear from the Apple iOS 8 release debacle is that some entity within Apple decided to release without the approval from the QA and Release team responsible for testing features and installation.
More surprising is how Apple had no immediate backup plan available to it's customers to conveniently roll-back to the previous iOS7 installed version.
This is very un-Apple like.
It's doubtful that the QA team would approve of a release with obvious product issues such as not being able to connect to a cellular network or Touch ID when those features are front-and-center and the core of what the iPhone does, and these issues were most likely known by the QA team beforehand, or, they were not aware of any late changes to the product that broke the features without the team having either 1) not enough unit testing by the dev team, or 2) not enough time to validate these changes were working properly.
Either way, the Apple/iOS QA team was put in a no-win situation and not capable of validating the product with a disorganized process, possible non-existent unit testing by the development team, and lack of patience in allowing the QA team to verify, to the fullest extent, the best possibility of a great release and identifying product risk.
The QA team knows more about your product than anyone else and has passion for customer satisfaction, pleasant user experience, and overall intuition about how the customer will interact with installation and product features. Listen to them and allow for the QA team to impact quality.
One thing very clear from the Apple iOS 8 release debacle is that some entity within Apple decided to release without the approval from the QA and Release team responsible for testing features and installation.
More surprising is how Apple had no immediate backup plan available to it's customers to conveniently roll-back to the previous iOS7 installed version.
This is very un-Apple like.
It's doubtful that the QA team would approve of a release with obvious product issues such as not being able to connect to a cellular network or Touch ID when those features are front-and-center and the core of what the iPhone does, and these issues were most likely known by the QA team beforehand, or, they were not aware of any late changes to the product that broke the features without the team having either 1) not enough unit testing by the dev team, or 2) not enough time to validate these changes were working properly.
Either way, the Apple/iOS QA team was put in a no-win situation and not capable of validating the product with a disorganized process, possible non-existent unit testing by the development team, and lack of patience in allowing the QA team to verify, to the fullest extent, the best possibility of a great release and identifying product risk.
The QA team knows more about your product than anyone else and has passion for customer satisfaction, pleasant user experience, and overall intuition about how the customer will interact with installation and product features. Listen to them and allow for the QA team to impact quality.
Tuesday, August 19, 2014
Are you a tester or a resource to impact better user experience and product quality?
Every person involved with traditional activities within the software development testing industry are referred to as "Software Quality Assurance" resources immediately realize that someone hired as a QA resource cannot impact quality of the product. They are hired as merely testers, and the only product/deliverable from these people are information about the product in that capacity.
Smart and capable VP/Directors of Engineering who really understand this realize the obvious:
1) Traditionally, QA people are hired mostly with intent of only being software testers, and testing has no impact on better software quality. Testing provides information about the product in its current state. This information is to better inform the team of more accurate product readiness.
2) Traditionally, QA people are expected to be entirely responsive to the development team's schedule, testing environment, and the development team is much more greatly appreciated and coddled to rather than the mostly neglected QA teams' effectiveness, passion, and contribution to the company's product roadmap objectives.
And the response from these managers are:
1) Respect the QA teams' concerns about user experience and product quality based on the findings and understanding of the test results.
2) Completely understand and acknowledge the leadership and intent of feedback from the QA team is entirely because of sincere concern for good user experience and product quality.
3) Acknowledge and promote the QA team's accomplishments, especially when it involves meeting the challenge to a reactive situation that they don't control, i.e. like working on weekends because the development team didn't meet the code freeze deadline.
4) Understand and reward test automation innovation and be open to acknowledgement of the effectiveness of these tests and how it benefits the customer experience and every resource in the company.
If you are a QA person, then eventually you will need to decide to accept being merely a tester with no meaningful impact on product quality, or stepping up and being a leader and positively impacting quality.
If your current company does not offer opportunities to meet your career goals as a QA professional, then quit your job. Your future employer will appreciate your initiative, talent, and passion.
Smart and capable VP/Directors of Engineering who really understand this realize the obvious:
1) Traditionally, QA people are hired mostly with intent of only being software testers, and testing has no impact on better software quality. Testing provides information about the product in its current state. This information is to better inform the team of more accurate product readiness.
2) Traditionally, QA people are expected to be entirely responsive to the development team's schedule, testing environment, and the development team is much more greatly appreciated and coddled to rather than the mostly neglected QA teams' effectiveness, passion, and contribution to the company's product roadmap objectives.
And the response from these managers are:
1) Respect the QA teams' concerns about user experience and product quality based on the findings and understanding of the test results.
2) Completely understand and acknowledge the leadership and intent of feedback from the QA team is entirely because of sincere concern for good user experience and product quality.
3) Acknowledge and promote the QA team's accomplishments, especially when it involves meeting the challenge to a reactive situation that they don't control, i.e. like working on weekends because the development team didn't meet the code freeze deadline.
4) Understand and reward test automation innovation and be open to acknowledgement of the effectiveness of these tests and how it benefits the customer experience and every resource in the company.
If you are a QA person, then eventually you will need to decide to accept being merely a tester with no meaningful impact on product quality, or stepping up and being a leader and positively impacting quality.
If your current company does not offer opportunities to meet your career goals as a QA professional, then quit your job. Your future employer will appreciate your initiative, talent, and passion.
Tuesday, May 20, 2014
The high cost of bugs found by the QA team
The average time it takes to find a bug, enter it into a bug tracking system, and then verify the fix is around 30 minutes.
The higher amount of bugs found equates linearly to the cost of product functionality verification per QA team member. As a team, it equates exponentially.
That is real time and money spent on a reactive and non-productive, non-quality impactful action to product quality.
If you feel that the development team is introducing an excessive amount of bugs into the QA environment that you test against, then be sure to bring that up in an Agile Retrospective, and provide ideas for process/quality improvement. The customer, and your company's CFO will appreciate your effort in reducing costs and promoting better product quality.
The higher amount of bugs found equates linearly to the cost of product functionality verification per QA team member. As a team, it equates exponentially.
That is real time and money spent on a reactive and non-productive, non-quality impactful action to product quality.
If you feel that the development team is introducing an excessive amount of bugs into the QA environment that you test against, then be sure to bring that up in an Agile Retrospective, and provide ideas for process/quality improvement. The customer, and your company's CFO will appreciate your effort in reducing costs and promoting better product quality.
Tuesday, May 6, 2014
Development2014 - Day 1 highlights
I was very fortunate to attend and present at Development2014 in Millbrea on Monday, May 5, 2014.
Gateway Analytics Network did a great job setting it up and I learned alot.
I learned about Kanban, Parc business updates and strategy, and Scaled Agile. Amazing stuff.
Gateway Analytics Network did a great job setting it up and I learned alot.
I learned about Kanban, Parc business updates and strategy, and Scaled Agile. Amazing stuff.
Subscribe to:
Posts (Atom)