Bad practices for a Software Test Engineer

People mostly talk about the good and the best practices but it is also important to know the worst or the bad practices which a Software Test Engineer must not follow or practice. At times people don't know what they might be doing wrong unless they are being shown the right direction.

So as a software test engineer we should not follow the below given bad practices:

1. Do not start working on tickets which are not properly defined or described. Unless proper description or methods are provided to test a certain functionality, one should not immediately jump on it. Rather a software test engineer should communicate proactively to find the details with the product manager or developers and then then put those details in the ticket and then start working on the same.
2. Do not test too many things at one time. If there is time crunch then one should only focus on testing the basic functionality first and then test cases with medium or low priorities can be tested.
3. Do not automate all the test cases from day one. This is the worst practice and mindset to follow when one has started writing test automation. First only the highest priority tests should be automated, monitored, fixed for bringing in stability. Once a test engineer feels that the tests are stable and the test environment and other requirements are stable enough to be relied on with confidence, then only medium and low priority tests should be automated.
4. Do not work quietly and be secluded from the team. Please do interact with everybody in your team and treat all as if they are your friends. Be open in expressing your views and yet remain professional. Remember a good communication, friendly and healthy team relationships are always valued everywhere. 
5. Do not discourage any team member if someone is giving some ideas or suggesting some new process or solutions. First listen patiently and then be a part of healthy discussion. Blocking or not letting someone speak or straightaway rejecting suggestions indicates you are no team player and nobody would like to work with you by their own will.
6. Do not try to show or boast that you know everything. This kind of behavior is not social rather you should be like a mentor and humbly show the right solutions or directions. 
7. Do not be too descriptive or too short in test documentation. Too much of data is also boring and not interesting. Less information or data also is not welcome as it proves to be useless then. Be accurate and be precise. 
8. Do not try to hide reports, breakages, defect leakages and outages/incidents. This will bring you bad impression and will hamper your rapport. These things are caught sooner than later and then does more harm than benefit. Instead be transparent and humbly accept the mistakes, ensure that you will work to make sure they don't happen in future and provide full analysis on the current or arrange a post mortem session for the same.
9. Do not avoid putting too many nitpick comments while reviewing a peer's pull request. Rather be a bit generous and only point out genuine issues with the code. Never try to delay or stop progress if you personally don't like the colleague. This is most common occurrence in places where the work culture is very competitive and everybody wishes to succeed faster. 
10. Do not be slow in responding to emails or direct mentions on Slack etc. If one is fast and active it generally makes the Devs and managers feel that as a test engineer you are always on your feet and ready to deal with any type of situations.
11. Do not stop communicating with higher management regularly. Make sure you meet at least a product manager, or an engineering manager or a technical program manager from your team once a week. Make sure that you know what they expect from you, what are their problems and try to solve them or suggest ideas or solutions. This will make them see you as a valuable resource and will help you grow.
12. Never stop helping other Test Engineers, Devs or Managers. The more you help the better you understand things and the better relations you establish in and out of your team. Being a part of team and helping others succeed, helps you succeed too.
13. Never feel shy to learn even from someone you don't like much. Like and Dislike are just emotions rather the larger goal is to acquire knowledge. So bury the hatchet and bring forward the friendly and cheerful side of your personality.
14. Never try to discredit someone if their role/contribution was lesser than yours, remember a team wins if all in the team wins. 
15. Never confront someone rudely if there is a disagreement. Rather discuss peacefully with open mind. 
16. Never work overtime on things that you could do in a much shorter span of time if you could have managed your time properly or could have done those activities in allotted time slots per day. Like creating a test report of last night's failures. If you would work on the same at the time of your daily sanity testing then you could apprehend what would happen. So make sure you do the work that is required in desired time slots and manage your time better.
17. Know when to stop trying and when to ask for help. If there is test case to automate on which you have spend a day already and there has been no success. So do not waste more time on it and ask for help from someone. Also the point here is to not straightaway ask for help if you will do that then you will never learn and always go asking for help. 
18. Never hesitate to escalate the situation to higher management if the work is not progressing and is dependent on someone. This should not be done in bad intention but only when you are waiting for a dependency for your testing to complete but the progress is not being made or is being delayed without any appropriate communication.

I will bring more light into such bad practices in upcoming blogs but in case you wish to learn GOOD Practices and wish to be successful in an Agile Test Environment. Please take a moment to read my book Click Here

Why you need to be prepared before starting as a test engineer in agile environment?

Why do you need to prepare before exam? Why do you need to preheat oven before baking? Why do you warm up before exercising?

For all of the above questions the answer is same so that you are better prepared and ready for what follows.

In the same way you need to be prepared when you are going to get started as a software test engineer in agile environment. Agile environment and agile development or testing methodology is fast paced and competitive.

If you miss a deadline, if you leak a defect or if you fall behind a task then whole product life cycle can change and sometimes can have drastic effects on future and upcoming projects which are in the pipeline.

So the best way to get ready is know and be well prepared to perform as expected and even surpass the expectations set on you. In Silicon Valley and globally too there is has been a trend where work culture has evolved from being easy to tough, and cut throat competitive.

Every day more and more qualified engineers are coming in the job market and some of them are toppers, some of them have more skills than others etc. Also there is already a pool of experienced software testing professionals in the market who compete to get the best job, best salary, best role, be benefits and best of everything.

So think if you are not prepared and jumping in agile testing or agile development and you don't know how work is done in this methodology. How you will cope with it, what are the tips and best practices you need to follow to succeed and grow. What terminology it is based on, what processes are being followed, how testing is done, how work is assigned, and many more such questions. How do you plan to get answers for them. Do you plan to work and learn that is good strategy but it is all catching up rather being in the action and performing at your best.

So if you feel what this is all about and if you think you wish to learn. In order to get your learning back on track and be prepared to win in agile testing please read my book available at link below:

http://mayankmohansharma.blogspot.com/2017/04/my-first-book-published.html

Mentoring in Software Industry

Many times people think that mentoring is just training people and making them learn certain skill set by giving few classes and the jobs' done. Rather it has all of these things like tutoring, knowledge transfer or knowledge sharing etc engulfed in itself.

Mentoring is lot more than just training and advising people. It is actually you as a Mentor taking responsibility and ownership of making sure that whoever you are mentoring becomes successful and learns how to use certain skill set or knowledge for personal and organizational growth.

Mentoring means following up regularly and monitoring the progress closely. It means making people understand technical topics easily and ensuring that people remember these things without much revision.

For example: if you tell a person that bash_profile is a file that saves certain paths and configuration settings on your mac and this file gets loaded before your terminal loads shell environment etc. Then it will be very difficult for someone to understand this. But if you tell them that a bash_profile can save short forms or aliases for certain commands that you use or type usually, and it can also be used to save path to a certain directory under a shortcut or can be used to save certain access keys etc then the person will remember this for long and can easily know what the practical application of the bash_profile is.

Mentoring helps a Mentor to understand judge his/her capabilities and also lets them know that how well they communicate. Another important aspect of mentoring software engineers is that we need to keep track of all the mentoring/training sessions with proper documentation. This helps people to easily follow the steps and follow the instructions when they need to recall something in future.

1. Make fear go away: Make sure that you infuse confidence in your mentees that coding or learning a new tech tool or programming language is not difficult and they have nothing to fear as you are always available to help them
2. Go easy with sessions: Plan sessions to go easy on the mentees. Make sure the initial sessions are short and are precisely pointing out the ways by which it will help them.
3. Always have practical exercises during sessions: Remember only theory never helps unless your mentees are armchair detectives. A little bit of practical session will always help them retain the knowledge for long and will give them opportunities to ask questions and explore.
4. Document as you go: Document each session as you go along giving training sessions. This will help in future by providing references and create a central knowledge repository to share and expand.
5. Test and Analyze: Regularly take frequent quizzes so that you can judge the level of understanding that mentees are holding.
6. Encourage: Give kudos to good mentees so that they are motivated to do even better.
7. Give space to explore on their own: Give them time to explore certain problems on their own so that they can develop self-exploratory and problem solving skills.
8. Continue the above cycle: Proceed with the above points until all the desired skill sets are developed.

This is how I perceive and try to mentor software engineers. Feel free to provide suggestions/feedbacks. Thanks for the read!

Later on we can deep dive in to how it actually works but the first step is to make people understand the need or application of the thing we are trying to tell them about

How to approach participating at Hackathons or Innovation Weeks

Nowadays Hackathons or Innovation Weeks are organized in almost every company. The goal of these type of competitions are to bring out the hidden talent or ideas from employees which otherwise remains hidden. These talents or ideas or concepts remains hidden because first of all there is always lack of time. Second thing is that the priority of actual work is always greater than any other thing for an employer. 

So when you get time to do something you have always wanted to do at your workplace in terms of being creative and floating and trying out new things then this is your time to show what you have it in yourself.

Here are few points to consider when you are planning to work on something in the upcoming Hackathon or Innovation week:

1. Try to find solution to a problem that is related to your work and your boss also agrees with you that it should be solved. 
2. Be clear of scope of the problem on which you will work on as sometimes can be very huge to solve and you cant get whole of it covered.
3. Make sure you have the right and balanced team with you. 
4. Building a team and working with your team is very important for those professionals who feel and have got feedback that they are not very good team players.
5. Have a pitch ready that clearly states your problem statement and what is your approach. A point or two stating that how this problem has been a bottleneck will strengthen your case.
6. Work by enjoying this time with your team don't stress out too much.
7. Be focussed on the minimal viable product approach and do not try to put much in at first go.
8. After the MVP is done make a brief plan on how you would like to go with it in future. 
9. Provide estimate of how much time it would take to make the final product ready for deployment.
10. Make the final presentation representing your ideas plus points and present it with passion like it is your startup idea.
11. Enjoy the win with team as there is no one actually loses when all work together for good.

Thanks for the read!

Get my book on Software Testing and Agile Environment from here!

Get and Read my book "How to start as a Software Test Engineer and be Successful in an Agile Environment" from the below given links:

It is available at below given links:

My Amazon profile as an Author: amazon.com/author/msharma

Audible, Kindle and Paperback edition: https://www.amazon.com/Mayank-Mohan-Sharma/e/B06Y3G4R75

Indian Paperback Edition: https://pothi.com/pothi/book/mayank-mohan-sharma-how-start-software-test-engineer-and-be-successful-agile-environment

Amazon India Kindle Edition: Amazon India Kindle Edition Link

Amazon India Paperback Edition: http://www.amazon.in/dp/9386503131

Flipkart India Edition:https://www.flipkart.com/start-software-test-engineer-successful-agile-environment/p/itmeuaq5acrhnggv?pid=9789386503138

Paytm India Edition: https://paytm.com/shop/p/how-to-start-as-a-software-test-engineer-and-be-successful-in-an-agile-environment-9789386503138_24933

Tips to be better as a Test Engineer in Highly Agile and Complex Environments

Test Engineers already are great and do their best to keep bugs and defects aways from products and services. Here are some tips I have learnt over the years that will just help them to be better. If you already know them then make sure you tell them to a Test Engineer you meet/talk with to make him/her also succeed. 

So here are the tips:

1. In daily scrums just don't listen the updates but think what you have on your plate for the day. Make it clear if something is ambiguous.
2. Adding a leaked defect to test suite does not help alone. A post-mortem of the cause of defect leakage for sure does.
3. Integrate Test Reporting with IMs for instant and hassle free report viewing.
4. Create bugs for any doubtful functionality or behavior.
5. Be proactive in communicating problems, achievements etc.
6. Estimate story points for each Testing Ticket so that you get ample time to test it.
7. Before automating or testing make sure your test data is accurate and can be prepared easily when needed. First apply effort in making test data creation faster and reliable.
8. Always communicate the test coverage to all stakeholders regularly.
9. Discuss with senior engineers and leads out of your immediate team also to find out ways to improve processes, tests, infrastructure etc.
10. Make a point to learn one new thing per day.
11. Be bold and speak out any thing that needs to be known to the team or stakeholders.
12. Build documentation with the code in form of inline statements etc. 
13. Take opportunities to mentor new team members.
14. Remember planning and strategizing is always welcome even if the time provided is minimal. Prioritization can make your life much easier here.
15. Fast and close communication with Devs is the fastest way to get a bug resolved.
16. Think retrospectives as the time when you are playing judge of the process/project and have to suggest improvements and tell about shortcomings fluently.
17. Give advance notice of personal time off etc for team to plan ahead. 
18. Mark your absence as "OOO" next to your name in present day messaging systems like Slack, Hipchat etc.
19. Create personal notifiers or bots that notify you when something related to your area of expertise is being talked about at Instant Messaging Systems.
20. Enjoy and do team outings! Make Testing Fun!

Tips to succeed in Highly Agile and Complex Environments

I have got opportunity to work in all types of software development methodologies from waterfall to v-model to rapid prototyping to agile. I have been very grateful to all companies and people I worked with who have helped me learn so much in such a vast and highly technical industry. 

Today I would like to share few tips which might help fellow test engineers in getting successful while working under a highly agile testing software development methodology. But first I will tell what is agile methodology and how work is planned under it. 

• An agile testing methodology has usually one or two weeks sprints or cycles in which a product manager/program manager, engineering lead/manager, engineers, test engineers, designers come together to plan out their work for the upcoming week or 2 weeks. This is basically called Sprint Planning.
• Work is usually measured by story points or effort required which in turn is given weights using Fibonacci numbers i.e. 1, 2, 3, 5, 8, 13. 
• Work usually includes new features and products but could include backlog of work and bug fixes. 
• All the work is tracked by tickets (most favorable tool at least in Silicon valley is JIRA). 
• All the people sit together and create/update/assign the tickets. Doubts are clarified and any deadlines/priorities are discussed openly. 
• Once the sprint/cycle ends all people again come together to do a retrospective of what went well, what could have been done better, who gets the applaud for outstanding contribution. This meeting also targets on getting feedback most importantly on how everybody can work more efficiently and how the processes can be improved further. It is a fun meeting and very important part of agile process. 
• Also important part of agile methodology is daily scrum. When all the team members come together every morning to discuss planned work for the day. Any hiccups/hurdles/dependencies  are discussed. It is also used to give heads up for any planned or unplanned release that might happen during the day. 

So this was agile methodology in short. A highly agile work environment would have all this done in short sprints with multiple releases and very limited time to automate or test.

In such work highly agile work environments here are some tips to be successful:

1. Managers/Leads: Create a release calendar which could be updated every day for any unplanned releases and have planned releases visible on them for transparency.
2. Devs: Mention tickets as QA or noQA so that test engineers need not waste time on figuring things out.
3. Devs: Mention steps to test particular ticket.
4. Test Engineers: Mention steps to reproduce bugs with screenshots and related metadata.
5. Product Managers/Program Managers/Project Managers: Set a kick-off meeting for any features etc for clarification of work, related doubts and dependency on other teams.
6. Raise alarm or incident immediately in order to avoid further delays.
7. Test Engineers: Write test automation first for the highest priority tests only in case of newly developed features in testing.
8. Test Engineers: Run nightly jobs for test automation so that build health is checked daily.
9. Share knowledge of testing and build environments with everybody in the team to debug and report issues without any dependency on any particular engineer.
10. Most important have documentation/Readme(s) for every work/repositories.
11. Set time to transfer knowledge, clarification of doubts or do group testing as and when required.
12. Team-Bug-Finding Exercises: Invite all engineers/managers/design team/product managers of a team to find bugs/defects in a new feature. This will help in building more collaboration, share knowledge of product with all the team members, and any doubts etc could be cleared instantly. 
13. Get the test plan reviewed by product manager and engineering lead/manager for making sure the coverage is proper.
14. Publish achievements to larger audience when the product is ready and released for visibility and work recognition.
15. Write technical papers/white papers on something that could benefit whole industry.
16. Work for the success of the team if that happens then individuals automatically succeeds.
17. Interact regularly with team mates and managers to find out pain areas and try to work on solutions.
18. Enjoy work and happy hour both :)

Thats all thanks for the read once again. I hope this helps!

Best Practices for Mobile Test Automation

Best practices learnt by experience for Mobile Test Automation are:

• Scope decision for Mobile Test Automation in highly agile workflow should be based on the following priority levels i.e. Top -> Smoke Tests, Medium -> Regression Tests, Low -> Features Related Tests
• Which Test Automation Tool Programming Language has to be used? This decision should be made on the following: 

1. Does automation of smoke tests or basic functionality require any API/Backend support that is designed in some specific language (hence that preferred should be used for test automation preferably to easily extend or reuse the existing architecture)
2. Does novice testers needs to be trained for automation which have manual testing exposure or comes from non-engineering background? In this case natural language based or record/play type of tools and supporting languages should be used. (Don't want to quote specific examples here)

• Which test automation tool to be used? 

1. This decision depends on several factors that a combined decision or understanding can answer this. For example how big is test automation requirement if it is not huge and apps are completely native plus no specific requirements are on the design patterns to be used then native UIAutomation tools can be used. One advantage in using native UIAutomation tools is that they get direct support from the mobile platform owners and is usually robust. 
2. If there is large number of tests to be automated and the application is relatively complex then the tests should be based on a design pattern and can use pretty advanced third party test automation tools
3. In case the test automation has to be parallelized and integrated with Continuous integration systems then we should use design patterns, third party tools and also cloud based test automation environments along with a solid CI solution which is difficult to find currently but yes whatever is available solves the purpose

• An effective test automation tool should always have a solid reporting mechanism based on the organization requirements.
• Test Automation Coverage should also be tracked in order to derive useful metrics and efficiency/productivity derivations.
• Tests should be independent of any device/simulator and should have conditions to tackle runs on all types of mobile test environments.
• All test automation should majorly focus on two aspects first is to help in shipping faster and secondly reduce manual test dependencies.
• Tests should always avoid explicit waits at any point and have sufficient retries and conditions to avoid these.
• 3 phases of test automation should go in parallel for a highly agile workflow else test automation is bound to fail i.e. development, execution and maintenance. In order to avoid failure prioritization and scope has to be define in pretty solid terms beforehand.
• Page Object Pattern is generally the most efficient design pattern for mobile test automation.
• Agile process should include suitable workflows for inclusion of test automation enabling accessibility labels/ids.
• Reusable methods/functions should be designed to reduce redundant test steps as much as possible.
• Use of human readable function/variable/method/class/abstract method names should be used. 
• Code with complex logic handling be marked with suitable justifying comments to avoid fellow test automation QAs understand your logic.
• Tests should be written such that failure of one does not affect any other test running in parallel to fail. Sequential test run model should be avoided unless absolutely necessary. Parallelization is the key to test automation success!
• Each part of a test should be configurable for user/data inputs. No hard coded values are appreciated in the real coding world.
• In the end all genuine code review comments should be acknowledged and be used as learning points for future test designs.
• The best teacher for test automation is your self do as much as you can and you will see that you are innovating and passing all hurdles with ease.

Thanks all for the read, I will keep sharing the goodness as and when I will learn more by experience and by hands-on!

Big Data application in Software Testing: An Enormous Growth & Research Opportunity

No matter what tools we use, what scripting language, what processes, design patterns, approaches, strategies, types or methodologies we use. Software Testing has always remained the same i.e. being "Function Centric" only. The ways has been different in order to verify and validate the basic functionalities under test but largely the motive has always been the same.

But now the paradigm shift is beginning to take place, which might be seen by some people who likes to think about the future. The shift is towards the way technological applications' are used and how efforts are being invested in order to study the usage or usage patterns of these technological applications by end users. 

For example if there is a mobile app that tells about the latest football match score many people can use it differently as per their preferences. Like a normal football team fan use it to see whether his/her team is winning or not by only checking scorecard in midst of his daily job schedule. A second user can use it to watch live telecast of the match. A third user can use to it bet on teams, A fourth one to track only his/her favorite player and also a fifth one who can use it to see that when the match might finish and at what time he should hit the road (that has the stadium in its path) to reach his home on time to attend his kid's birthday party.

So there can be a lot many use cases where an app can be used differently apart from it's basic functionality. Now most of the companies are today concentrating on this basic functionality that focuses more on their business model and USP of the app itself. This is what is absolutely right as per the today's utilization of their app's service solution. 

But as we are gradually witnessing the role that usage analytics based on Big Data utilization is playing these days, we can say that the days are not far when applications has not only be tested for their basic functionality but also for other logical patterns; the information provided by these applications can be or is being utilized knowingly or unknowingly by the end users. 

In the present day we have seen an exponential rise in analytics tools that can deliver all the hardware/software platforms end users are using, navigational paths, conversion rates, most sold item, least read book chapter, crash analytics, performance statistics, location based usage and many more kind of analytical informations. 

This is just a tip of expanding global industry we are witnessing. The present day scenario is that the tools are good enough to deliver these stats upon some triggers but they are incapable to help us look more into a kind of expandable map of possibilities or provide meaning to this data more precisely. Currently the product managers or developers or testers make sense out of this slightly cooked data to improve there applications. But what I see is an approach that is easy to follow from today itself such that we can use this Big Data more effectively for testing and making products far far better.

Few ways by which we can visualize the possibilities of Big Data based Analytical Testing are:

• A tool which can draw all the usage patterns of the app, visually depicting all the possible navigational paths for example: paths of the most frequently used UI navigations map etc. Tool should be capable of dynamically assigning paths with respective weights as the app is being used by end users to make a real data real usage based prioritization testing plans/strategies etc.
• Users' usage patterns based on real time events/occasions sometimes defines usage of applications in unique ways so coverage of those scenarios to provide more value other than the basic functionality. This would require analysis of entry and exit points to the applications and pre and post event analysis.
• Capture of frustrating or appreciating moments of usage of the applications apart from reviews, ratings, emails etc i.e. conventional methods. 
• Testing of user desired capability expectations in scenarios the requests can be instantaneous and from unprecedented platforms e.g. if a user does a verbal query from his LG G-Watch for the latest position of a pizza van. But suppose if this feature is only provided on website by that respective company then this might prove to be potential bad customer experience. Although the basic functionality of the app still is functioning perfectly on the website. But still that platform rendered not useful for this customer who is driving and wants to just know the status spoken up by his smart watch. In this case company restricted customer of using real time update just because company never came to know that there might be around 50 users that can do exactly the same thing again or some of them have even tried and failed earlier, making them shift to some other pizza vendors. 

These are only a handful of ways that I have provided in order to make you all think that what all other ways can be there and how we can develop or envision them in order to make software testing more advanced and more useful than its present day applicability. 

Artificial Intelligence & Software Testing + The World of Artificial Gene Synthesis induced Artificial Intelligence!

More on Artificial Intelligence and Software Testing:

There is a lot of discussion/debate going on, in the high-tech research fields based on artificial intelligence and its implications on software testing. It is being foretold that intelligent machines like IBM Watson can take over all forms of testing in coming decade or so.

Initially artificially intelligent entities will not be fully aware of their own self. And the process of generating result oriented thoughts/solutions either by induced stimuli or by mere observations will still be a thing of distant future for them. They will not be suitable for jobs where they can create, design or develop according to set protocols and give desired outcomes.

So the next best use of their "artificial-intelligence" will be based on learning how to test or verify & validate a particular functionality as per desired behavior. This AI can be set to try and match the observed results with expected results. And in this due process; the gradually learning artificial conscience can learn to perceive, observe, and judge the observations as accurate or erroneous based on the desired functional patterns.

To understand the underlying concept:

Think that you are being asked to create a pencil that writes with ink instead of carbon lead. The first step to solve this problem will instantly start with imagining a pencil in our mind. And then later we will proceed to think of ways to put ink in the pencil structure and so on and so forth. 

But imagine if somebody has not seen a pencil with carbon lead or a pen with ink refill. How this person can start his thought process, what should be the initial step for him to proceed with? 

Now consider the same person who has played with a pencil and pen both. He knows about its functionality, its shape, color and other properties. If the problem is now asked to this person he will have a starting point to proceed with and there is a possibility that even, if he has limited intelligence capability, he can imagine a pencil with a pen refill inside it. 

What we observed from this example is that to test and to verify/validate is not a job where intelligence is not required rather a job which helps instill a thought process. In such a way that concepts related to the functionality-under-test or validation/verification becomes clear. And sets a path which leads to an actual functional result oriented outcomes. Rather than just a series of failed attempts without any clear point of intelligence incubation.

So the initial applications that we wish to derive out of AI would be more test-centric rather development-centric. In more crude words it will be a baby step towards actual testing from simple tasks of Verification & Validation.

Now another point is that no Test Capable AI also can start without an initiation. Initiation point for this will be a different kind of test data which will give a hint of pattern to this AI in order to initiate the perception, observation and start applying the judgment in testing the functionality.

Mathematically and by the usage of suitable computational resources these concepts will be tested and provided with stats to approve or disapprove them.

Biologically induced Artificial Intelligence:

Now we will talk about a new concept that I thought of while going through the videos of Dr.Craig Venter in which he remarkably presented the creation of artificial DNA sequence. This work can be of great potential in sequencing artificial DNA structures that can work on perception of input patterns and provide results in the forms of algorithmic self-assembly structures. 

When these algorithmic assemblies will be compared to an expected result the test can be said to be verified or validated. 

To understand this concept think of a much simpler problem i.e. 2+3=5. Now the initiation to test this equation will be the already set: algorithmic self-assembly structures by which we can define each known integer respectively. 

The first step will be to perceive that there is a pattern where integers are only used. AI can narrow down its observation patterning capability to only integers now. Now when the this observation will be provided to test to the DNA, it will react to the stimuli and would arrange itself in a uniquely identifiable self-assembly structure. 

This structure will validate/verify that the result is integer, & function to be tested was addition. Hence the result will match the observation with expectation successfully.

As this technology will be based on DNA, Self-Assembly, A.I and possibility of mutable DNA structures as complex reasoning pattern assemblies. It will show us the window towards developing a possible integration of electronics with genetics resulting in computational genetics/artificial genetics induced intelligence or Artificial DNA based Intelligence Simulation. Also as the DNA will be artificially cultured, it can be made perishable; hence human or human(ely) controllable (debatable topic). 

There is a lot what we can achieve through this new convergence of Artificial Genetic Structuring with Artificial Intelligence. And there are immense number of possibilities where it can be put to use in order to give astounding results.

So until this is proved and implemented, let us keep exercising our brain muscles and delve into the amazing world of technology and science.

Lessons to be learnt from Mr.Narendra Modi for IT Management

I have been always a keen follower of Mr.Narendra Modi's (Renowned Indian Politician) thoughts on his governance, growth and development methods. 

He has recently become a more impacting and youth driving + motivating sensation in India, with millions of motivated youth from urban and rural parts of India following him and wishing him to be next PM of India. 

The few lessons that he conveys to public in his rallies are of such unique but brilliantly vibrant that they can be applied everywhere to give astounding results. I wish to derive the learning aspect of his speeches to devise methods that can make IT Management a very focused route in order to benefit all i.e. client, team, ourselves and employer respectively.

So here are the points:

1. Never Think of Becoming Someone rather Think of Doing Something: This mantra tells us the root of success in life. When a person thinks of becoming somebody important with power or prominence, it can hurt sometimes if the dream is not accomplished because not always you get what you want, not always the results of your hard work pays in the same amount you toiled for it. When this failure is encountered a person might get demotivated in life and can lose the sight on goal. Rather if you think of doing something which has importance, it motivates the person to deliver in short term goals which progressively leads the person to the larger goal and ultimately success. At times if a person loses the sight of short term goals or feels demotivated he can easily come back by realizing his stagnation or turmoils or mistakes. So now how can I apply this in managing an IT workforce. If we set target for our teammates on short term goals like automating parts of functionality each week, developing this part of code each week rather than giving them a bulk task of automation of complete payment procedure or developing code for complete checkout process. If we break the task it is easier to manage. In the same way if we think of earning a post of Delivery Manager we need to see that how well we are able to understand the basics of development while we are a novice developer, how will we advance on my skill set this year and how will I learn to mentor our juniors next year. Slowly like this when we pass the successive year we can later focus on leading team, innovating ang try to give value to client and then save company cost and increasing earning revenue. Working in the direction of doing something with excellence leads us to position of excellence and once this work habit is developed nobody can stop us from personal, social or organizational growth.
2. Never look upon someone, never look down on someone rather look collectively towards achieving a goal: This suggests that we should neither look over somebody with self-proclaimed superiority, nor we should look over somebody thinking that he or she is weak, without self-decisive point of view. Rather we should look in ways that how we can contribute with him or her in order to achieve a common goal together. If we waste our time in petty hatred building views in a group or team we can never succeed both personally and collectively. In a team we should try to allocate jobs as per person's dire interest and fore-see how this allocation can be done in order to collectively drive the team towards its set goals. For example if there is a young programmer who does not code well but is good in criticizing other people's code and on the other hand there is a software tester who can find discrepancies in code. This young programmer and tester would normally in real world be asked to continuously do the same job on  daily basis even though there vested interests are in opposite roles. But if we don't look upon or down on there performance and adopt a collective approach of problem solving keeping the interests of our code base quality as the benchmark of success we can easily switch the roles and see if this really works. If it works it is good for the team and them if not we can see how there roles can be slightly modified so that they can become code reviewer and software developer engineer for testing respectively. Thus solving both the problems and creating a win-win for all.
3. Life is choosing between intense hard work, hard work and smart way of working:  People can do the jobs in 3 ways, people  achieve their goals in 3 ways, people life is also governed by these 3 ways i.e. by doing intense hard work, or by doing hard work in general, or by doing work smartly. Suppose there is functionality to be tested this can be done by covering all the test scenarios manually on all the required platforms by working day and night i.e. intense hard work. This can also be done by combining automation and manual testing by covering all scenarios on all platforms i.e. hard work.Third is using cloud based automated test environments for test scenario execution in parallel yet covering all the scenarios. So the essence is that no matter hard work is always rewarded but smarter way of doing work is appreciated, it saves valuable time, earns benefits and above all develops a way of thinking to do things unconventionally. This out-of-the-box thinking makes us smarter and helps us in making our work more efficient and productive. 
4. Come together to Grow together: If we come together in a team and participate in each and every decision taken by the team management whole-heartedly we have better chances of succeeding together. Rather if people within the teams are divided in sub-groups who does not keep their points or discuss their issues going forward in a particular direction it becomes difficult for all to come together and work towards a team goal. Slowly all members lose interest and neither the team goals are achieved nor the individual goals are achieved. But if all members discuss things and resolve issues beforehand and then work towards a goal whole-heartedly it increases the probability of succeeding. Effort should not be made in the direction of avoiding or alienating team members if they are not willing to co-operate but towards finding ways so that all come together for the same.
5. Freedom to Work as per own's interest for some part of the day:  I personally have experienced the same in my team once. There was Software tester in my team who liked to think about new product designs and innovative products he always was full of wonderful ideas to discuss. But he was going nowhere with them as his job was just the mobile apps for the client. Once a manager thought of giving him some time to analyse the mobile apps and provide some feedback. After 2 days the draft version of app features suggestions he proposed were so marvelous that client's marketing head wished to meet him in order to work on the same ideas he proposed. This is the power of doing what we like doing the most. In IT companies if for identified individuals who have shown some interest based caliber in doing something different that in turn can benefit the project/product should be encouraged.
6. Growth for all is the solution for all problems: In a team if there are 50 IT specialists, then a lead or manager should have a plan from beginning to ensure growth for all these 50 members from day one. If a lead or manager fails to do so, the team will lose talent, team members will lose interest, team will lose targets, and like a domino effect everything will fail one day. And one day the lead or manager will have to escape and witness the downfall over the shoulder's of new lead or manager.
7. More the power lead/manager has distributed to subordinates the more powerful the team will be: If a person or 2 person have all the power and tries to manage everything then the team or system will fail. If the person-in-charge distributes the power to capable subordinates and in return looks into solving problems that these subordinates cannot solve, will make a team more productive. Rather than wasting time in managing subordinates. 
8. A Creative Man is motivated by Desire to Achieve but not by Desire to Defeat others: Suppose if I try to compete with a fellow architect and try to defeat him by doing few things better than him. What really I would be doing is that I will be limiting myself to the capabilities of the other guy and concentrate my energy in working on skills that will make me only competitively superior to the other guy. But if I work to compete with myself if I challenge myself that OK if I can design an effective architecture for developing High Performance Cloud Services for Healthcare then how can I better myself in reducing the throughput to a much lower level. If I work in this direction then I will be taking my knowledge and skill set level to a much higher standards rather than wasting my time on petty individual targeted advancement of skill set.
9. Life is 10% what happens to you and 90% of how you react to it: Suppose I get a low performance appraisal this year so shall I stop performing and stop enhancing my skillset, shall I stop going to office, shall I stop enjoying my work? No if I get something that I don't deserve then I should have the self-esteem and confidence to show the management that what I am capable of. If a person works undeterred towards his/her goal no matter how long he/she has to work he/she achieves what he has always deserved. No hard work goes waste no learning is useless. If we wish to go ahead and succeed we should learn to tackle 10% of hurdles with 90% of positive and powerful determination.