A lesson out of “Lessons Learned in Software Testing”: Lesson 272

If you can get a black belt in only two weeks, avoid fights.

The past few weeks I have been involved more than usual with performance reviews and learning about South Africa’s Cyber crime future. It brings back memories why I enjoy what I do and how I got to where I am today, yet I still feel like a novice. This feeling of inadequacy reminds me of the lesson I learned the hard way when I was 8 years old and after attending 4 Karate lessons over a period of a month.

For most people starting out in testing (or anything for that matter), many things are based upon blindly accepting what you are being taught as the truth. And that’s perfectly in order. This drives the economy to some extend as well. Blind faith is a prerequisite for ultimately transcending your boundaries of knowledge, hopefully arriving at a higher level of understanding in the end.

People don’t realize this, but confusion is very real when thrown into/with the “meat grinder” to suddenly test and magically “improve” a product’s quality against all odds. Generally inexperienced people, confusion is typically “resolved” by:

• “Just tell me what to do.”
• “Then tell me how to do it.”
• “And if I’m ready for it, maybe even tell me why to do it.”

Anything more will just terrify most people.

Over the past 10+ years I was involved, or actually making a living out of testing. I came to realise that most things in life takes time to become an expert in, or even just good enough. You have to make a lot of mistakes. You then have to fix your own mistakes as well as those mistakes made by others. Many training courses promise you a certification, diploma and expert knowledge. Be careful, just because you managed to pay for skills/knowledge does not make you an expert or efficient if you cannot apply that to the context of the situation at hand.

However, I have to admit, if the skills/knowledge is so simple and repetitive to be able to master in just two weeks, by all means do it, but don’t try to fix and improve disasters.

If you want to improve your skills in testing, read a lot, ask questions, and practice. Your career will take things away from your personal life. Sometimes the “sacrifices” can be quite high, but make sure you learn from your decisions as this will help you build on your current experiences.

About the source:

http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124

Paperback: 320 pages

Publisher: Wiley; 1 edition (December 31, 2001)

Language: English

ISBN-10: 0471081124

ISBN-13: 978-0471081128

A lesson out of “Lessons Learned in Software Testing”: Lesson 23

 

A tester is more than a tourist.

This can be somewhat of a challenging to explain. The definition of a tourist is a person who is traveling, especially for pleasure (according to dictionary.com). Now the definition of “pleasure” can also pretty broad and also depended on perspectives. In my view, a tourist is someone who follows the group and the only documentation they have are the flyers from the sights they visit, and of course the hefty credit card expenses. It makes sense if you think of what the purpose is of testing and also realise that testing is not cheap. Yes, you may be able to argue that tourist take photos, but there’s a good chance that you will be the only one who knows what you did in that moment in time and the emotions you had going.

What is the value of a tourist then when so many teams use you as a “tourist”? Hopefully a ROI of what you “invested” in making things pretty to attract tourists. Make sure you are evaluating the product and not just watching.

When testing, stop thinking like a tourist, but start thinking of Livingston, start to think like an explorer. Get some excitement going!

About the source:

http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124

Paperback: 320 pages

Publisher: Wiley; 1 edition (December 31, 2001)

Language: English

ISBN-10: 0471081124

ISBN-13: 978-0471081128

Let’s Test South Africa – Nov 15-17 2015

 

Join us in Magaliesberg, November 15th – 17th 2015 for some fun energetic alternative sessions on Sunday evening aimed at getting to know people and reconnect with old friends.

http://lets-test.com/?page_id=4065

A lesson out of “Lessons Learned in Software Testing”: Lesson 55 + 58

A lesson out of “Lessons Learned in Software Testing”: Lesson 55 + 58

You are what you write.

Your bug report is your representative.

Warning someone or telling them something is wrong is an activity we do in our everyday lives. The stop sign on the corner of the road is warning you that there can be fatal danger ahead if you do not stop. The roadwork’s sign informing you that something strange is happening up ahead and that you should be careful. Even a pregnancy test has clear instructions to follow and what the possible expected results could be, if used correctly of course. Trust me, I know!

The challenge we face is the ability to inform someone, of something, in writing, that they will be able to understand. Programmers rely on our reports to be able to investigate the problem and hopefully fix it. It’s like telling a police officer what happened. For some this is comes naturally, for many, not so much. Sometimes, even the reader of your report will fail to follow your clearly defined instructions. Remember that the programmer(s) are not the only people that will read your report.

Some common mistakes I find when reviewing incident reports (bug reports) are:

1. Spelling and Grammar mistakes to a point you think the writer is alien.
2. Missing or inaccurate steps to reproduce the issues.
3. Missing, incomplete, or inaccurate preconditions required to reproduce the bug.
4. The expectations and any references to what were expected.
5. The number of times it reproducing this bug.
6. No indication of a possible workaround.
7. The severity of the bug.
8. Any attachments to support this bug.
9. Being emotional.

A nice exercise is to log a bug and see if your friend, family member, or peer can reproduce it.

Remember, the bug reports you created will be your representative. People will share your bug reports from the dev team straight up to some board members. Everyone that is a decision maker may have a chance to read your bug report. Imagine if they don’t understand what you have written or unable to reproduce it. They will either throw it away, meaning you wasted your time to document the bug, and everyone who read your bug will mostly subconsciously degrade your value to the team and question you contribution to help identify risks to build confidence in the product.

Remember, writing good (bug) reports is crucial from intern level upwards.

Ironically, in my personal experience, people are more willing to repeat multiple pregnancy tests just to make sure of the outcome. Does your bug report create the same impact?

About the source:

http://www.amazon.com/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124

Paperback: 320 pages

Publisher: Wiley; 1 edition (December 31, 2001)

Language: English

ISBN-10: 0471081124

ISBN-13: 978-0471081128

Games Testing: Doom (Closed Alpha)

Doom is going into a closed Alpha testing cycle. This is an exciting opportunity to put those reflexes of yours to the test again and help making more reliable games. Hopefully this game will not require a 10GB patch on launch day.

Based on the video the scope appears to be as follow:

1. Multiplayer Component
2. Very limited content and functionality ( 1 map, 1 mode, 1 demon )
3. Gameplay mechanics
4. Performance Testing ( Load, Stress )
5. PC (via Steam), PS4, XBOX One

For more information visit http://doom.com/en-gb/alpha

A lesson out of “Lessons Learned in Software Testing”: Lesson 183

This is a post from an email I sent out to my peers while working at Dynamic Visual Technologies (http://www.dvt.co.za) to create awareness and start discussions.

---

Test opportunities arise whenever one person hands off an artefact to another.

---

I find it tiringly interesting when dealing with stakeholders involved with any type of development when it comes to testing. Seldom stakeholders will dare to raise the abyssal question: “how do we validate and verify this?” aka test this.

It might be a fear of rejection, fear of sounding “negative”, or the fear of hearing the truth. From my personal agonising experience, first you need to identify who are the stakeholders, then who will use this feature or product, then figure out why and how they could use it, and then rephrase the question to be more appropriate for the audience so it is more in line with their function in the business and involvement in business process.

For example:

To The One (Neo) who runs the business: “How can we measure your confidence in the quality of this product so that your product single handily will blow your competition out of the water?”

To the fraud/security team: “How can we make sure this product will pass(measure) your rigorous and much required checks without wasting your time or stressing you out?”

To the project manager: “How can we measure which risks are either eliminated or mitigated to not blow your timeline and budget?”

To the developer: “How can we make sure (measure) we don’t get buried down with change request, maintenance, bugs and overtime under pressure without looking like a bunch of fools?”

To the tester: “Say buddy, how can we prove (measure) this thing should not see the light of day and prove it’s not our fault? 😉 ”

The moral of the story is, a bug matters to someone. Find out who matters and communicate in their language what they will be happy with for you to measure.

Tell us how you experienced this in your career. I believe we all can learn from each other and laugh together about it.

About the motivational source:

Title: Lessons Learned in Software Testing

Paperback: 320 pages

Publisher: Wiley; 1 edition (December 31, 2001)

Language: English

ISBN-10: 0471081124

ISBN-13: 978-0471081128

Don’t do testing if you need to hide something

The automotive industry had a fun week with VW getting busted for running software during tests to fake the results of their diesel CO2 emissions. Even the stock prices plummeted around 24% wiping out about $17 billion in shareholder value.

Apparently around 11 million diesel cars sold globally are outfitted with this software. This could even include Audi and Porsche brands. How the software works basically is that when the vehicle gets hooked up to the test bed the equipment switch over to the “illegal” software. This will then lower the emissions around 40 times. When unhooked, the vehicle will switch to the default software and provide higher performance.

Now it is probably okay to get mad at the automakers, but this might also have exposed some gaps in the environmental protection agency’s emissions testing practices. The good news is that this woke up regulators worldwide and all automakers might be under eagle eyes to make sure they are not burned again.

So the lesson this situation bring to light is that if you have something to hide, don’t bother testing. The purpose of testing is to gather information that will provide sufficient data to make an informed risk-based decision if the product is fit for use. (hopefully by an educated individual)

I think this also brings a little bit of perspective that standards should sometimes also be questioned based on the context of the product or system under test.

Lessons Learnt : It’s Apple with their iOS update – again- …sigh

 

So, last week Apple had an issue with pre orders for the iPhone 6 and 6S.

This week Apple made it to the press again but with their iOS9 release. Many of those who tried downloading the update were slapped in the face with a very “informative” error message “software update failed”. Apparently according to news, Apple didn’t respond to a request regarding this issue. Then again, it’s not uncommon for users to experience these types of issues when there is such a high download demand. Also, if you just browse the interwebs and see all the complaints from users that their apps crash after the update should make you chuckle a bit before you take another sip from you 20 year old Scotch. Remember when iOS8 launched? It came packaged with nice bugs (free of charge) regarding Wi-Fi and Touch ID system. Then a quick patch provided the users with more fun bugs (still free of course). I don’t understand, but Apple updates iOS every year and keep it interesting to its users and keep developers “making” apps for its device.

There are also a few articles around why you “want” to install the iOS iPhone OS ASAP…Protection from hackers. Remember the iCloud hack? I have no issues with the raunchy photos that leaked though, we all watched discovery channel once in our lives. But don’t dare steal my credit card details!

What can we learn from Apple so far? Well, one is that if you have a large user base of die-hard Apple religious consumers…performance and security does not matter…Bad news is still free advertising. This however question our role in testing vs business. If you can justify in money terms the risks of not performing a certain test or getting a certain bug fixed, then business does not care. Remember, the test you are performing need to have value (yes, many businesses out there still don’t understand this yet and we are trying very hard to convert them). If the test is not going to find bugs that can threaten and close the business, why are we sometimes so eager to spend time writing and maintaining low value tests?

We have to act like professionals before business will treat us like professionals.

Testing Experience Issue 25 – Crowd Testing

http://www.testingexperience.com/

Interesting topics covered in this issue around crowd testing. My experience with crowd testing started with beta testing games…for free. These days companies actually pay for this service. I tried uTest a few years back. Very interesting how to manage the testers from around the world and collecting results.

Some of the things that annoyed me as a crowd tester was technology constraints and trusting the developers. I don’t feel always so confortable installing their applications on my device or using my Facebook account to test their products. What drove me over the edge to bail out was the test management infrastructure and performance measurements. The system of that time deducted points/reputation from your profile for not excepting a request to test, even if you did not have the required device.

This service is a great experience for new testers to gain some in the field experience. If it is managed correctly this service can be great for companies.

The “Software Testing World Cup” 2014 is coming!!!

http://www.softwaretestingworldcup.com/

This will the first official worldwide competition for software testers! According to the site  more than 4000 software testers will be participating in the continental preliminary rounds. Sign up at the site and show what you can do.