Tuesday, 23 May 2017

When should a tester engage in testing?

Test Early
Image Credit: https://cdn-images-1.medium.com
- Why should I hire testers at an early stage of a project and not just during the testing phase?
- Why should I let my testers test early?
- How can I hire and retain testers?

- How testers can evolve as PRODUCT ENGINEERS?

- And finally, why software testing is not a boring job?

Here is an attempt I made to address these questions.
As far back as my memory goes, I have been an advocate of testers involving themselves in the SDLC right from the beginning of a project. I have questioned when no testers were invited to the Architecture Review Board meeting at a previous firm that I earlier worked with.
I strongly wish that testers start contributing to a project from it’s discovery phase. Right from when the decision is made to build the software. This means that we do contribute to building the product right from the beginning and are not mere time wasters of programmers (coder/designer) who have already spent considerable amount of time learning about the product, data modelling, coding, unit testing and deploying the code to the test server. And who then will have to pass on all the (or filtered) knowledge to a tester just before or during the testing cycle. Does it annoy you as a programmer?
Point to ponder here: Is this the reason why programmers are paid more as compared to the testers? Let me restate it for the testers: Is this the reason why the testers are paid less as compared to the programmers?
Moving on: How can I as a tester contribute from the beginning of a project?
Here are some solutions on how testers can collaborate with the client / Product Owner, programmer, designer, SEO engineer, security analyst and contribute to each phase of software development.
Requirement Gathering Cycle
When the client / product owner shares the requirement, resolve to this:
As a tester, I want to refine these requirements based on quality criteria so that I will not contribute to cost, effort and time wasted at the last phase of a project.
And do thisShare a clarifications log with the client with the assumptions, clarifications and suggestions to enhance the requirement.
The clarification log can consist of columns in a sheet with these details:

|Query |Clarification by the client / Product Owner |Priority| Implemented in sprint|
Example: The user is able to download the report. 
As a tester, you can ask:

Query |By user do we mean a guest user or a logged in user in this context?
Clarification by the client / Product Owner | Both the guest user and the logged in user
Priority | Low / Medium / High 
Implemented in Sprint | Sprint number

Above is an example of the clarification(log) which we maintained throughout the product life cycle by the whole team in a startup I worked at. The programmers then become better equipped to add both the scenarios of making the report available for a logged in and a guest user.
Understand and refine the requirement/s when we receive it so that as a tester you can start contributing to the quality of the product and build credibility for yourself right from the early stages.
Design Cycle
Develop skills required to test the design / wire-frames. Some references are below:
Test for user flows / navigation, user behavior in the design cycle. Do not wait until the end of functional testing to begin with User Interface and User Experience testing. We are responsible for a user forming good habits when they use the software built. Let us make every click count :)
Development Cycle
Test the code that is being developed for missing validations, known vulnerabilities and bugs, ask for access to the code, database and learn what is being implemented as part of a fix and what is the impact of the fix. This helps us as testers to learn about the fix and the impact early on. And help identify a bug during the coding cycle and in fixing it then rather than wait for the fix to be made, unit tested and deployed on to the test server to be tested and then for the bug to be logged in the bug logging system to be fixed and re-tested.
This to me sounds like waste of valuable time for all involved.
Testing Cycle
Now that a lot of time has been invested by you in testing at different cycles of the project, utilize the testing time effectively to test the system post integration. Take time to learn about effective bug logging, interactions with the application, it’s users and invest time to gather user feedback and enhance the product suitably.
Release Cycle
Proceed confidently to the release cycle. Take time to test the release notes in dev/test/beta phase. Check for version numbers, fixed bugs section, whether adding this information creates an impact, can we do away without adding the trivial details. Those users who will read the release notes (which is not equal to the number of downloads) are unforgiving if there is nothing new that they can learn post reading the notes. Add value by bug logging and enhancing the product quality at this stage too.
Maintenance Cycle
Use this time to work on those low priority bugs and get it fixed and re-tested along with the other bugs found by the team / user feedback / suggestions / user reviews that you read.
Invest time earned to learn, take testing courses, give talks, attend webinars and conferences, invite users to test and to gather another test idea. Up-skill to remain relevant in the ever changing and ever growing industry.
Investing early efforts to test can help address major problems which we are facing as testers.
1. No time to test.
2. Building credibility early on.
3. Knowing that this credibility eventually gets translated to respect and testers being treated equally with the other roles in an organization.

My question for you today is: Do you recognize valuable respected testers around you? 
If yes, make them your mentors today. They are waiting for you too :)
Earlier published : https://blog.whyable.com/test-early-904c337696f1

Wednesday, 10 May 2017

Few pointers to the translator

Certain translations that I came across triggered me to add some recommendations to the translator (someone who works on translations) who is yet to recognize or who undermines the value that they create by adding translations.

As I reckon that it is essential for a translator:
Click on the image to view it in an enlarged form.
  • to possess language skills (reading, writing, speaking)
  • to have knowledge on the tools used and 
  • to develop a sense of onus and service to the community.

In the above example:
The author, Girimane Shyamarao has written a book titled: 'I / Myself, Children and Education' but the translation roughly is made to as you see 'I have children and education'. Such slip can be avoided if we meticulously learn the language, the meaning/s of the words used and in a contextual manner.

Some recommendations are now part of the guidelines that I had earlier created when I was involved in translating some educational project for Khan Academy. Thanks to my mentor Julian Harty for encouraging me to volunteer to translate.

A few lessons learned are shared below in the form of a mindmap.

Click on the image to view it in an enlarged form.
Or refer the images below.

If this write-up inspires you to take up translation work, then do create an account with Khan Academy here: https://www.khanacademy.org/ and volunteer to contribute.

Saturday, 6 May 2017

Socially Challenged By Social Engineering

Socially Challenged By Social Engineering - A study on Social Engineering trends in corporate culture.

Troy Hunt had advertised his Ethical Hacking course availability on Twitter, and since then I had wished to opt for Pluralsight learning (where it was made available). I got ample opportunities to implement the lessons I was learning this week.
A few scenarios that were opportunities in disguise for me to exercise the lessons learnt are as follows:
 — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 1

The first attempt — Creating a sense of urgency.
A co-worker let’s say ‘X’ who had met the team twice and had spent considerable amount of time knowing the work we do, had wished to seek some more information. And it came as an email request. This information which needed to be shared, yes was secure information.
What seemed obvious at first but suspicious next was that there was a sense of urgency in the email sent. “Need this information by end of day”. It did not though say who was the consumer of this information.
While I made genuine effort to fetch the information, it occurred to me that — Why is X asking me this information? (When X knew someone else in the team who had spent a lot of time with X and had built a rapport already).
So, I cross checked with all the others in the team. I inquired, “Did any of you get a similar request to share this information?”. The answer was ‘No’. I registered this.

The Second attempt — Introducing an unknown character.
My next suspicion was, X had made an indirect attempt to seek information via a new supposedly a ‘girl’ (before sending the email request). This girl was unknown to me. I wondered ‘who could this be’ when I got the request from this stranger. There was no attempt made by X to introduce the ‘new girl’ to me. This was the give-away move. Because when X knew me, ‘why’ make an attempt to introduce a stranger to seek this information. What was X thinking? Now that X has realized what he did and has spoken to me about it, I will attempt to know the why. 
Interesting at the same time suspicious to know why introduce a ‘new girl’ when X who knew me, could have directly contacted me.
Next day, the ‘new girl’ started pinging me (and again with a sense of urgency) to gain this information which was by now was already asked over an email by X. ‘New girl’ then told me that person ‘Y’ wanted this information. I did not know who Y is nor I was introduced to Y before or during the conversation. I clearly replied, I do not have access to this information and as I have replied over the email, let us wait for the authority to grant us the access. And I included Y in the email who was the ‘CONSUMER’ of this information.

The third and the fourth attempt: Cause fear and threaten.
Rest assured, I bid the new girl bye benevolently and logged off. Then X who obviously is aware that I have not given the new girl any information so far, calls me on my phone and it is evident from the start of the conversation that he is not in the right frame of things. X then tried the third mode: To cause fear in me to gain access to the information. When that did not work, X then uses the fourth mode: threatens me by conveying that ‘I will go to the highest level of escalation’. I am calm,very composed as I knew that I am not the authority to give X this information even if I had access to it.
To brief, Person X’s tries / attempts to gain information are as follows:
  • Create a sense of urgency for reasons (valid / invalid).
  • Introduce an unknown person (a girl, don’t know why?) — This being the incorrect move for obvious reasons. X had undermined himself as the first POC to reach out to me and had caused me to have my first suspicion. Please take note how this gullible new girl was victimized in the entire process.
  • Cause fear which then culminated as a threat.
  • Know and seek information from right sources.
  • Quote valid reasons for seeking the information.
  • Inform who is the end user of this information so that it can be sent directly to the consumer and not to the others who should not have access to this information.
  • If the seeker is the end user, then it can be helpful so the mediators do not gain access to this information.
  • Learn and know how to talk to anyone.
  • Educate the gullible, they need help.
This scenario not just helped me implement what I was learning but also led me to another knowledge source. When I was at a book store recently, my eyes lit up when I saw this book 'Maatu Hegiddare Chenna'? authored by Girimane Shyamarao (ಮಾತು ಹೇಗಿದ್ದರೆ ಚೆನ್ನ, ಗಿರಿಮನೆ ಶ್ಯಾಮರಾವ್) which roughly translates to 'How words uttered must be?'. Now reading and it is a good read for anyone who wishes to be a good speaker.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 2

corporate social engineeringA co-worker ‘A’ was made an easy target for wrong doings of similar patterns from his past and the authorities were trying to action against A for the same. I wrote to A about the allegations that were made.
A was taken aback and replied with proofs on what was happening.
I probed further, as I had spent lot of time setting things right with A. This probe revealed that these were false acquisitions and was not done to offend anyone in the process. But A did reveal that he had only faulted with me and not with the others, assuming that I will forgive but the others wouldn’t. I rested this case, but was glad that I inquired to get the proofs when there were false acquisitions being made on A. When I reported the authorities about the false acquisitions, the authorities understood while they also exhibited suspicion that A could be lying.

  • Information coming from a senior needn’t always be true.
  • Know that the an impersonator usually disguises as someone with authority, is trusted, is a senior, is legitimate, is respected. This doesn’t mean that you fear them but genuinely question and learn about the intention.
  • Learn from past mistakes and know when to stop.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —
Scenario 3

This is a case of:
  • An attempt to please a person with authority.
  • Fear of senior/s.
  • Not learning from the past mistakes.
Some give away passwords in plain text when merely asked to share only the username, this scenario occurred when a senior with a sense of urgency asked for information from a new joinee. Newbies are unnecessarily petrified, help them out and create a safe environment rather than instilling fear.
Do not leave mobile devices / laptops unattended, that can cause anyone in the vicinity to gain easy access into the system. Have strong passwords (policies) and be aware of the fact that there could be a threat lurking around. Educate and be better equipped to address security threats in the form of social engineering.

  • Educate the new joinee.
  • There is nothing to be feared, but only to be understand - Quoting Madam Marie Curie.
  • Instill a positive and safe environment to question and to learn from all.
  • Encourage learning and create a culture to reward learning.
— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — 
Final thoughts
  • It works isn’t sufficient. Know that SECURE systems are as important and for any reason security should not take a back seat. Introduce Secure Development Life Cycle at all stages of development.
  • Be aware of known vulnerabilities and address the security aspect of the system that we build and test.
  • Share professional information wisely to the right consumer.
  • Do not share personal information where it is absolutely unnecessary.
  • Do not encourage personal information seekers.
  • Beware of what you share on open source mediums. Know about OSINT — Open Source Intelligence. Know nothing is free, your data is what you trade for using open source apps.
  • Socially challenged is what we become if we fall prey to social engineering.